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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
