I have created the 1.0.x branch. It includes the latest changes from `main` branch - as I think all of those changes are useful in this branch.
If anyone thinks of the commits are a problem for this branch, we can remove the branch contents. On 2023/07/04 13:41:09 Matthew Benedict de Detrich wrote: > Oh and another thing I forgot to mention, there are of course some nuances > when it comes to bincompat. For example final is an example, i.e. you could > have an initial method which should have been final but you forgot to mark > it as such but you decide to add final later on. MiMa would flag this, > however if the initial method was never intended to be extended/overridden > and with proper investigation its found that no users are > overriding/extending that method then exceptions can be made in such cases > (as a general aside this is also the context why I was strongly pushing for > https://github.com/apache/incubator-pekko/pull/388 to be merged). > > Also on the topic of release branch names, I wouldn't get hung up on what > we ultimately decide to pick. Unlike version tag naming which is immutable, > points to actual releases, has tooling built around it and has well > established naming conventions branches are a bit more flexible and > changing an existing branch name should not be a big deal (either literally > or semantically). main of course is an obvious exception here. > > On Tue, Jul 4, 2023 at 3:20 PM Matthew Benedict de Detrich < > matthew.dedetr...@aiven.io> wrote: > > > Don't have any complaints with the strategy, we should have a branch for > > every major that we release (i.e. a one for 1.0, one for 1.1 one for 2.0 > > etc etc). The main thing is deciding on a strategy for how to > > backport/forward port changes between branches (I am a fan of cherry pick + > > PR). > > > > With regards to the name, this is one area where I disagree with Akka's > > naming of release-, I personally prefer 1.0.x, 1.1.x because this is what > > seems to be established in the Scala community. To me at least it's very > > clear i.e. the missing v indicates its not a single version (its a series) > > and the .x further emphasizes this. > > > > Regarding MIMA/binary compatibility. We should definitely enable MIMA once > > 1.0.0 lands for the respective Pekko modules. Since we are using > > versionScheme = SemVer (see > > https://www.scala-lang.org/blog/2021/02/16/preventing-version-conflicts-with-versionscheme.html > > and https://www.scala-sbt.org/1.x/docs/Publishing.html) we should > > actually not make any exceptions to binary compatibility for the interfaces > > where its relevant (i.e. InternalAPI/private is never covered by bincompat > > with InternalStableAPI being an exception). The reason I am being so > > hardline/strict about this is that the entire point of the versionScheme is > > that it actually makes sbt block dependencies being resolved if it sees a > > compatibility and although you can override this it then kind of defeats > > the point of having it in the first place. There may be some exception to > > this with critical bug/security fixes but we should verify this (at least > > with what Akka does). > > > > I also do believe that this strictness with binary compatibility is > > something that Akka followed and took very seriously, so it's not something > > that should be a shock to anyone. There are of course legitimate concerns > > in being that strict with bincompat, i.e. it does restrict us especially if > > we have API's that aren't well designed (for w/e reason) and we need to > > change them however this is part of software development. Another thing to > > note is that SBT does support custom rows via sbt-projectmatrix (see > > https://github.com/sbt/sbt-projectmatrix) which for example, if we make > > are working on Pekko 2.x that is source (but not binary) compatible with > > Pekko 1.x, we can share the sources between both, > > https://github.com/rallyhealth/scalacheck-ops/blob/main/build.sbt is an > > example of this in action. > > > > On Tue, Jul 4, 2023 at 2:51 PM PJ Fanning <fannin...@gmail.com> wrote: > > > >> Thanks Ryan. > >> > >> 'release-x.y' is what the Akka community use but I'm flexible about > >> the name. With tags, we are already using 'v1.0.0' style. > >> > >> With active development lines, I would imagine that 2 is a good start. > >> 1.0.x for important fixes to 1.0.0 and one forward development line > >> aimed at a 1.1.0 release. Once we see how stable things are, we can > >> review if we want to base releases around a schedule or if we just > >> release when it seems that we have something important to release. > >> > >> On Tue, 4 Jul 2023 at 13:41, Ryan Skraba <ryan.skr...@aiven.io.invalid> > >> wrote: > >> > > >> > I don't have a strong opinion on branching and names! I tend to avoid > >> > using the term "release" in a branch name since branches, by definition, > >> > are in movement and a release is a static event. But it's common > >> enough in > >> > ASF projects -- Flink distinguishes between branches `release-1.X` and > >> tags > >> > `release-1.X.Y` and it's never been a source of confusion. > >> > > >> > With my release manager hat on: It's much easier to keep on top of > >> commits > >> > when they are backported or cherry-picked at the same time they're > >> merged > >> > to main. Doing it as a future step (just before a minor release) is > >> > tedious and error prone! How many major + minor releases do you think > >> the > >> > community can maintain simultaneously? > >> > > >> > All my best, Ryan > >> > > >> > > >> > > >> > > >> > > >> > On Tue, Jul 4, 2023 at 11:32 AM PJ Fanning <fannin...@apache.org> > >> wrote: > >> > > >> > > Hi everyone, > >> > > > >> > > After we get the Pekko core repo released (along with the 1.0.0 jars), > >> > > we need to introduce branches. > >> > > > >> > > We need to be able to create patch releases and to open up development > >> > > for a future 1.1.0 release. > >> > > > >> > > I propose that we create a 'release-1.0' branch before we allow > >> > > forward development to commence on the main branch. > >> > > > >> > > With PRs, I suggest that they target the main branch first. If we > >> > > think that they should be applied to the 'release-1.0' branch too, > >> > > that should be discussed on the dev mailing list. > >> > > > >> > > We should reintroduce the binary compatibility checks to monitor for > >> > > any breaking changes relative to the 1.0.0 release. With the > >> > > 'release-1.0' branch, we would probably want to ensure that we avoid > >> > > binary incompatible changes unless they are absolutely needed. > >> > > > >> > > Even with the v1.1.0 focused changes, I think we need to come up with > >> > > an agreement about how far we want to go. I would suggest that we try > >> > > to minimise binary incompatible changes. If there is a shortcoming in > >> > > any existing API function and we need to change its inputs or return > >> > > type then we should probably deprecate the existing version of the > >> > > function and introduce a new function. > >> > > > >> > > Feel free to add your own opinions to this thread. > >> > > > >> > > Regards, > >> > > PJ > >> > > > >> > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > >> > > For additional commands, e-mail: dev-h...@pekko.apache.org > >> > > > >> > > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > >> For additional commands, e-mail: dev-h...@pekko.apache.org > >> > >> > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
