I wanted to do a little bit of cleanup as well as go through currently open issues/PR's for pekko-core and would have preferred if the 1.0.x was made after this since it would have reduced the change for merge conflicts in the case we ever have to cherry pick to 1.0.x.
@PJ Fanning <fannin...@gmail.com> is it a big issue for you to recreate the branch a bit later (like in a week or so?). I don't think we are in a rush to merge the feature changes right now (our focus will likely be on doing the rest of the pekko modules anyways). On Sat, Jul 15, 2023 at 4:58 PM PJ Fanning <fannin...@apache.org> wrote: > 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 > > -- 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
