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
