GitHub user mdedetrich edited a comment on the discussion: Should we allow 
'mixed versioning'?

> > By definition of semver patch bump's shouldn't add new functionality, only 
> > fix anything thats currently there so on surface level this seems okay
> 
> I don't know how strictly we plan to follow semver. For Akka, we've been 
> using it quite loosely, e.g. allowing new features in a patch release, and 
> this has served us well. If we continue down that path, loosening the version 
> check doesn't make sense.

So far with Pekko we have followed it strictly so there shouldn't be an issue 
if we decide to adhere to it.

The only exception to this is the 1.0.x series where we have been adding 
migration functionality in patch versions (this is the reason why I was pushing 
for making the original release 0.x.x and not 1.0.x).

> If we start following semver more strictly, and releasing 'minor' versions 
> more often, that means we'll be reaping fewer benefits from our binary 
> compatibility, putting pressure on us to release 'satellite' projects more 
> often, and possibly even releasing multiple version lines of various 
> components. I'm not sure that's the right choice.

So if we decide to follow this strictly this shouldn't impact anything as minor 
versions are meant to be backwards binary compatible with eachother (which is 
why new features should only be done in patch bumps as that breaks forwards 
compatibility and patch versions should be backwards, forwards and source 
compatible)

What it will do is add extra overhead as we will have a lot more branches to 
handle (1 branch for every major.minor). We have been doing a good job of 
automating away this overhead so I don't think it's too much for now but that 
is largely reflecting the current feature cadence that we have (which is not a 
lot)

GitHub link: 
https://github.com/apache/pekko/discussions/1483#discussioncomment-10669030

----
This is an automatically sent email for notifications@pekko.apache.org.
To unsubscribe, please send an email to: 
notifications-unsubscr...@pekko.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org
For additional commands, e-mail: notifications-h...@pekko.apache.org

Reply via email to