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 > >
