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
