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
