Re: plan for branching
Am Freitag, den 16.10.2020, 08:17 +0200 schrieb Michael Käppler:
> Am 16.10.2020 um 01:41 schrieb Dan Eble:
> > On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote:
> > > Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
> > > > After creating the branch, I will (unless somebody doesn't want me to
> > > > do this and volunteers to do the work; see also below):
> > > > - bump master to 2.23.0, in preparation for the next cycle;
> > > > - bump stable/2.22 to 2.21.80, in preparation for the first release
> > > > candidate;
> > > > - merge and / or forward the translation branch to stable/2.22.
> > > I'd like to do this tomorrow or Saturday at the latest, unless I hear
> > > objections before that.
> > >
> > > Jonas
> > Are there any concerns about merging
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/458
> > ("Sequential_iterator garbage collection") ahead of schedule? That's the
> > last thing I've got for the stable release.
> I do not have any concerns. But if I understood Jonas correctly, there
> will be
> some release candidates before 2.22, anyway and Jonas would cherry-pick
> fixes like yours into stable/2.22.
> So IMHO no urgent need for fast-tracking.
Yes, that MR was already at the top of my list for backporting.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: plan for branching
Am 16.10.2020 um 01:41 schrieb Dan Eble:
On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote:
Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
After creating the branch, I will (unless somebody doesn't want me to
do this and volunteers to do the work; see also below):
- bump master to 2.23.0, in preparation for the next cycle;
- bump stable/2.22 to 2.21.80, in preparation for the first release
candidate;
- merge and / or forward the translation branch to stable/2.22.
I'd like to do this tomorrow or Saturday at the latest, unless I hear
objections before that.
Jonas
Are there any concerns about merging
https://gitlab.com/lilypond/lilypond/-/merge_requests/458 ("Sequential_iterator
garbage collection") ahead of schedule? That's the last thing I've got for the
stable release.
I do not have any concerns. But if I understood Jonas correctly, there
will be
some release candidates before 2.22, anyway and Jonas would cherry-pick
fixes like yours into stable/2.22.
So IMHO no urgent need for fast-tracking.
Cheers,
Michael
Re: plan for branching
On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote:
>
> Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
>> After creating the branch, I will (unless somebody doesn't want me to
>> do this and volunteers to do the work; see also below):
>> - bump master to 2.23.0, in preparation for the next cycle;
>> - bump stable/2.22 to 2.21.80, in preparation for the first release
>> candidate;
>> - merge and / or forward the translation branch to stable/2.22.
>
> I'd like to do this tomorrow or Saturday at the latest, unless I hear
> objections before that.
>
> Jonas
Are there any concerns about merging
https://gitlab.com/lilypond/lilypond/-/merge_requests/458 ("Sequential_iterator
garbage collection") ahead of schedule? That's the last thing I've got for the
stable release.
—
Dan
Re: plan for branching
Am 15.10.2020 um 15:26 schrieb Jonas Hahnfeld: Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below): - bump master to 2.23.0, in preparation for the next cycle; - bump stable/2.22 to 2.21.80, in preparation for the first release candidate; - merge and / or forward the translation branch to stable/2.22. I'd like to do this tomorrow or Saturday at the latest, unless I hear objections before that. Jonas Please go ahead.
Re: plan for branching
Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > After creating the branch, I will (unless somebody doesn't want me to > do this and volunteers to do the work; see also below): > - bump master to 2.23.0, in preparation for the next cycle; > - bump stable/2.22 to 2.21.80, in preparation for the first release > candidate; > - merge and / or forward the translation branch to stable/2.22. I'd like to do this tomorrow or Saturday at the latest, unless I hear objections before that. Jonas signature.asc Description: This is a digitally signed message part
Re: plan for branching
Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld: > Thoughts? Something I forgot? I just removed translation-staging, which was equal to stable/2.20 signature.asc Description: This is a digitally signed message part
Re: plan for branching
On Tue, Oct 13, 2020 at 3:11 PM Jonas Hahnfeld wrote: > With the localization issues hopefully resolved and no objecting > comments to the last thread, I think we should go ahead and create > stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. > > After creating the branch, I will (unless somebody doesn't want me to > do this and volunteers to do the work; see also below): > - bump master to 2.23.0, in preparation for the next cycle; > - bump stable/2.22 to 2.21.80, in preparation for the first release > candidate; > - merge and / or forward the translation branch to stable/2.22. > > Thanks for taking this on! > - master is open again for feature development etc., eventually > released as 2.23.0 after 2.22.0 is done (note that it would be helpful > to avoid large-scale changes that complicate the following points); > I don't have plans for large scale changes (or any changes, actually) in the coming 1-2 months: I have been pretty busy at work last month, and I am moving apartments next week. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: plan for branching
Am Dienstag, den 13.10.2020, 15:38 +0200 schrieb Michael Käppler: > Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld: > > With the localization issues hopefully resolved and no objecting > > comments to the last thread, I think we should go ahead and create > > stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. > > > > After creating the branch, I will (unless somebody doesn't want me to > > do this and volunteers to do the work; see also below): > > - bump master to 2.23.0, in preparation for the next cycle; > > - bump stable/2.22 to 2.21.80, in preparation for the first release > > candidate; > > - merge and / or forward the translation branch to stable/2.22. > > > > As a result, > > - release candidates are cut from stable/2.22; > > - master is open again for feature development etc., eventually > > released as 2.23.0 after 2.22.0 is done (note that it would be helpful > > to avoid large-scale changes that complicate the following points); > > - fixes are developed, reviewed, and merged to master via the usual > > countdown cycle and cherry-picked into stable/2.22 once landed; > Sounds good. But my knowledge about these things is very limited, so > my opinion is possibly not that well-grounded... Neither is mine, as I haven't been around when the last branch was created. The list comes from observations of the git history, mailing list archives, and knowledge of procedures in other projects. > > - the same goes for the English documentation, which may be cherry- > > picked into stable/2.22 if applicable; > > - in contrast, translation targets the stable/2.22 branch to restrict > > the documentation to what's in there; I will try to cherry-pick those > > commits to master to avoid a similar situation we had after 2.20. > Did I get this right: > * _Fixes_ for the English documentation are applied to master and > cherry-picked to stable/2.22 > (Would this apply for restructuring work like the recent CG edits, too? > Or would they not be cherry-picked?) Any work on the English documentation happens in master, but only commits relevant to 2.21.8x and 2.22.0 are picked into the branch. This may well include the CG edits, unless we only want them to appear with 2.23.0. > * 'master' will not be merged into 'translation' (and vice versa) until > 2.22.0 is out, instead 'stable/2.22' will > be regularly merged into 'translation' and back. (Rationale: Do not let > translators spend useless work on > translation documentation for unstable features in 'master' that are in > flux?) Apart from the time effort, translation usually seems to happen per file or per manual. It would be unfortunate to advertise something in the (translated) documentation that is not available as of 2.22.0, but taking only parts of a commit is just too much work IMO. > * You will cherry-pick work in 'translation' during the upcoming period > (before 2.22.0) to master that the work > does not get lost Mostly yes. Putting that burden onto the translators seems unfair, and merging all changes after the stable release was a pain this time. I hope that picking the changes continuously proves to be manageable. signature.asc Description: This is a digitally signed message part
Re: plan for branching
Am 13.10.2020 um 15:11 schrieb Jonas Hahnfeld: With the localization issues hopefully resolved and no objecting comments to the last thread, I think we should go ahead and create stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below): - bump master to 2.23.0, in preparation for the next cycle; - bump stable/2.22 to 2.21.80, in preparation for the first release candidate; - merge and / or forward the translation branch to stable/2.22. As a result, - release candidates are cut from stable/2.22; - master is open again for feature development etc., eventually released as 2.23.0 after 2.22.0 is done (note that it would be helpful to avoid large-scale changes that complicate the following points); - fixes are developed, reviewed, and merged to master via the usual countdown cycle and cherry-picked into stable/2.22 once landed; Sounds good. But my knowledge about these things is very limited, so my opinion is possibly not that well-grounded... - the same goes for the English documentation, which may be cherry- picked into stable/2.22 if applicable; - in contrast, translation targets the stable/2.22 branch to restrict the documentation to what's in there; I will try to cherry-pick those commits to master to avoid a similar situation we had after 2.20. Did I get this right: * _Fixes_ for the English documentation are applied to master and cherry-picked to stable/2.22 (Would this apply for restructuring work like the recent CG edits, too? Or would they not be cherry-picked?) * 'master' will not be merged into 'translation' (and vice versa) until 2.22.0 is out, instead 'stable/2.22' will be regularly merged into 'translation' and back. (Rationale: Do not let translators spend useless work on translation documentation for unstable features in 'master' that are in flux?) * You will cherry-pick work in 'translation' during the upcoming period (before 2.22.0) to master that the work does not get lost Thoughts? Something I forgot? Jonas Thank you, Jonas, for all your effort!
plan for branching
With the localization issues hopefully resolved and no objecting comments to the last thread, I think we should go ahead and create stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0. After creating the branch, I will (unless somebody doesn't want me to do this and volunteers to do the work; see also below): - bump master to 2.23.0, in preparation for the next cycle; - bump stable/2.22 to 2.21.80, in preparation for the first release candidate; - merge and / or forward the translation branch to stable/2.22. As a result, - release candidates are cut from stable/2.22; - master is open again for feature development etc., eventually released as 2.23.0 after 2.22.0 is done (note that it would be helpful to avoid large-scale changes that complicate the following points); - fixes are developed, reviewed, and merged to master via the usual countdown cycle and cherry-picked into stable/2.22 once landed; - the same goes for the English documentation, which may be cherry- picked into stable/2.22 if applicable; - in contrast, translation targets the stable/2.22 branch to restrict the documentation to what's in there; I will try to cherry-pick those commits to master to avoid a similar situation we had after 2.20. Thoughts? Something I forgot? Jonas signature.asc Description: This is a digitally signed message part
