Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please don't use the version field to differentiate parallel artifacts #592

Open
nafg opened this issue Jul 29, 2022 · 6 comments
Open

Please don't use the version field to differentiate parallel artifacts #592

nafg opened this issue Jul 29, 2022 · 6 comments

Comments

@nafg
Copy link

nafg commented Jul 29, 2022

The difference between interop between CE2-ZIO2 and CE3-ZIO2 etc. is not that one is a newer version than the other. They are separate artifacts. They should have separate artifact names.

The version field should only be used when the same artifact evolves.

Otherwise tools like Scala Steward, sbt-updates, Renovate, etc. become useless. And they are very valuable.

@tschuchortdev
Copy link

Yes, please! I just ran into this problem. Section 10 of the SemVer spec mandates that metadata like this should be appended with a plus sign, which automated tools will ignore.

@nafg
Copy link
Author

nafg commented Sep 22, 2022

It's not metadata. They are different artifacts. They are parallel paths of development.

@nafg
Copy link
Author

nafg commented Sep 22, 2022

This is the same way that cross publishing for Scala versions and Scala.js versions works.

@neko-kai
Copy link
Member

@nafg @tschuchortdev

I almost agree that it would be more convenient to have them as separate artifacts instead of versions, but then the different series aren't honestly 'separate' artifacts. You can't use more than one of them at the same time because you can't use multiple versions of ZIO or cats-effect at the same time.

Both ZIO and cats-effect have made the same choice to retain the same artifact names while doing breaking rewrites AND they keep releasing new versions in their different respective version series – that too breaks Scala Steward and others – Steward keeps bothering you to upgrade to ZIO2 or CE3 if you keep using ZIO1 or CE2, the way to fix that nagging is to use steward's settings to block updates to new major versions – it supports that. The nagging is somewhat intentional too, you have to eventually upgrade to the latest versions of these libraries - it's unlikely the old versions will be well supported forever.

@nafg
Copy link
Author

nafg commented Mar 14, 2023

The nagging is somewhat intentional too, you have to eventually upgrade to the latest versions of these libraries

That is precisely the point. In the case of ZIO itself (and many more examples), there is a single ordering 1.0.17 < 1.0.18 < 2.0.0 < 2.0.1 etc. If I have code that uses ZIO 1.0 and I can't be bothered to migrate it yet, that's fine but the whole point of Scala Steward is to nag me about that.

But if I'm using zio-interop-cats 12.0.0.1 then when it comes to zio-interop-cats I only want upgrades to 12.0.0.2. Version 23.0.0.0 is not an evolution of 12.0.0.2, it's a different use case. And they aren't version numbers because they don't follow an ordering. 23.0.0.0 is not "after" 12.0.0.2, for instance.

But instead, Scala Steward will not tell me about 12.0.0.2. It will only tell me about 23.0.0.2. There is no reason it should be like that.

It is no different than publishing for different scala versions. If I'm on Scala 2 I don't want Scala Steward to give me the Scala 3 version of ZIO. Improvements to ZIO-for-scala-2 come out all the time and Scala Steward knows not to give me the Scala 3 artifact because they are implemented as parallel artifacts.

I can see the benefit of using git functionality to keep the parallel lines of development in sync, but that just underscores that they are parallel. I suppose it would be more complicated to have separate artifact names with a common version but I could help set that up. Also, it doesn't have to be a common version -- you could continue using the same exact version scheme but just use a slightly different artifact name on each branch.

@neko-kai
Copy link
Member

neko-kai commented Mar 30, 2023

@nafg

Scala Steward will not tell me about 12.0.0.2. It will only tell me about 23.0.0.2. There is no reason it should be like that.

In my experience Scala Steward did create PRs for 13.* series upgrades in https://github.com/7mind/izumi/ - we're still on ZIO 1 too - although I may have closed the 2* series PRs before that.

In the case of ZIO itself (and many more examples), there is a single ordering 1.0.17 < 1.0.18 < 2.0.0 < 2.0.1 etc. If I have code that uses ZIO 1.0 and I can't be bothered to migrate it yet, that's fine but the whole point of Scala Steward is to nag me about that.

The single ordering argument applies to Cats Effect and then transitively to this artifact. The version series' beside 23.* aren't exactly 'parallel' lines of development, they're more like LTS releases for people willing to bear the cost of staying behind the ecosystem (and eventually having to fork / take over development of old versions if they realy want to stay on old versions forever). There very much is a single ordering here - you should neither stay on CE2 nor on ZIO1, nor on interop-cats version for these long-term.

Improvements to ZIO-for-scala-2 come out all the time and Scala Steward knows not to give me the Scala 3 artifact because they are implemented as parallel artifacts.

You can fix this by forbidding updates to versions other than 12.*/13.* in .scala-steward.conf. You have to make the choice to lag on versions explicitly, I think that's fine to be honest.

I suppose it would be more complicated to have separate artifact names with a common version but I could help set that up.

Implementing this isn't an issue, but I think that ideologically that wouldn't be correct. The upstreams - ZIO and CE - have made the choice to release the same artifacts and packages with new versions, forcing upgrades, making it impossible to mix old and new versions and signalling that new versions supersede the older versions. As a utility artifact we should follow, especially since it's already impossible to use different interop-cats series at the same time due to upstream choices anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants