On Mi, 31.07.19 12:57, Tomasz Kłoczko (kloczko.tomasz@gmail.com) wrote:
> As usually that type of versioning convention is rubbish and it only adds
> more work on packaging layer.
> Why you guys did not released that as v243.99 ?
I like my bikesheds blue.
Yes. Today is a bit sunny in London.
Thanks for asking .. and ignoring that rc<num> versioning convention adds some overhead on packaging layer.
Your bikeshed argument is really powerful so I can only give up.
> Other thing is that looks like systemd devel cycle elongated and it cased
> that some stabilisation fixes are only committed in master branch with all
> other changes.
>
> Proposal for next systemd devel cycle:
> - create devel branch and commit all devel changes in that branch only +
> stable fixes
> - commit in master branch only stable fixes and release more ofthen v244.1,
> v244.2 and so on (one time a month or even more often depends on importance
> of the fixes)
> - release candidates starting from v244.99
> - when everything in devel will be ready just merge devel branch to master
> and tag it as new major release.
Are you volunteering to do the work for this? Or do you just expect us
upstream to maintain twice the amount of releases?
We don't want to be consumed in just doing release mangament. It's
hard enough, and we definitely prefer if developers focus on one
master, not many, and stop developing new stuff while we are in release
mode. This means, doing parallel branches for upstream development is
not in the cards, sorry. Either everyone stabilizes or everyone works
on new stuff.
Note that there's a "stable" backport tree maintained outside of the
main repo:
https://github.com/systemd/systemd-stable
In other words you asking me voluntary do the job which is already done.
Nice. OK, I'll take that job.
kloczek