So 2 features that I wanted to get merged did so (i.e. https://github.com/apache/incubator-pekko/pull/509 and https://github.com/apache/incubator-pekko/pull/511), so after the few remaining trivial PR's are merged I am happy with updating and then protecting the 1.0.x branch.
One issue that came into my head is the versioning, more specifically when the 1.0.x branch is prepared we ideally want to set the base version of the main branch to 1.1.x and the only way we can do that is by creating a git tag (hardcoding the version statically in build.sbt will prevent sbt-dynver from working). I was thinking an easy way to fix this problem is to push a v1.0.0-M0 tag as soon as 1.0.x is prepared. wdyt? On Mon, Jul 17, 2023 at 10:41 AM PJ Fanning <fannin...@gmail.com> wrote: > Sure - the v1.1.0 targeted PRs don't need to be merged yet. > > The 1.0.x branch is not protected (yet) so it can be dropped and > recreated - or it can be rebased and a forced git push can be done. > > On Mon, 17 Jul 2023 at 08:55, Matthew de Detrich > <matthew.dedetr...@aiven.io> wrote: > > > > 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 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 > -- 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
