2.20 and 2.21 release plans

classic Classic list List threaded Threaded
24 messages Options
12
dak
Reply | Threaded
Open this post in threaded view
|

2.20 and 2.21 release plans

dak

Ok, I think 2.20 is basically done and we should push it out by the end
of this week.  This leaves a few days for the translation team to catch
up with the current state.

In particular HINT HINT HINT it gives the opportunity to native speakers
of languages not as meticulously maintained as the currently most active
translations to at least tackle the Changes document and maybe check a
few other points of the web presence.  This is more addressed to people
reading this announcement on the lilypond-devel list than to lurkers on
the translations list, though of course the latter would be equally
welcome.

What does this mean for 2.21.0?  I think we should aim to push it out
fast afterwards, basically a few days later at most, just to get kinks
with webpage/versioning from 2.20 ironed out.

I am not sure it is realistic to expect to get the translations merged
into 2.21.0 already: because of the significant divergence experienced
so far, I expect this to be a significant merging headache.  It would be
nice to have, but not essential: this is the unstable branch after all.

For more extensive changes of internals and/or syntax, I would recommend
to let them sit till 2.21.1 before committing, assuming that we _do_
manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
significantly diverged from 2.20.0.  If something does not quite work,
it would be nice to have a _released_ version to compare to, and nothing
but 2.21.0 would really serve that role satisfactorily.  Particularly
where problems are detected a long time after getting introduced, having
an installable version as a reference is nice, and "it stopped working
in 2.21.0" is enough of a quagmire already that we do not really want to
add a lot more here.

The size of the headache basically is commensurate with how long the
stable branch has diverged.  Hopefully we manage to find some
combination of process and responsible persons next time around that
delivers faster.

Nevertheless, I am glad we are getting there.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

Jonas Hahnfeld
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the end
> of this week.  This leaves a few days for the translation team to catch
> up with the current state.

Wohoo!

> [...]
>
> What does this mean for 2.21.0?  I think we should aim to push it out
> fast afterwards, basically a few days later at most, just to get kinks
> with webpage/versioning from 2.20 ironed out.
>
> [...]
>
> For more extensive changes of internals and/or syntax, I would recommend
> to let them sit till 2.21.1 before committing, assuming that we _do_
> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
> significantly diverged from 2.20.0.  If something does not quite work,
> it would be nice to have a _released_ version to compare to, and nothing
> but 2.21.0 would really serve that role satisfactorily.  Particularly
> where problems are detected a long time after getting introduced, having
> an installable version as a reference is nice, and "it stopped working
> in 2.21.0" is enough of a quagmire already that we do not really want to
> add a lot more here.
Sounds good (well, Python 3 is already in). To be sure: This also means
we'll be using GUB for 2.21.0? I'd like to propose a new system (yes,
*with* support for Windows) soon, but not sure that I can make it in
the next week or so...

> The size of the headache basically is commensurate with how long the
> stable branch has diverged.  Hopefully we manage to find some
> combination of process and responsible persons next time around that
> delivers faster.

To throw this idea onto the mailing list: Time-based releases seem to
encourage a predictable schedule. I don't think it makes sense to have
monthly stable releases as, for example, GitLab does. But maybe
tracking something like once in a year to 18 months with defined
windows for alpha and beta releases?

Jonas

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

dak
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the end
>> of this week.  This leaves a few days for the translation team to catch
>> up with the current state.
>
> Wohoo!
>
>> [...]
>>
>> What does this mean for 2.21.0?  I think we should aim to push it out
>> fast afterwards, basically a few days later at most, just to get kinks
>> with webpage/versioning from 2.20 ironed out.
>>
>> [...]
>>
>> For more extensive changes of internals and/or syntax, I would recommend
>> to let them sit till 2.21.1 before committing, assuming that we _do_
>> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
>> significantly diverged from 2.20.0.  If something does not quite work,
>> it would be nice to have a _released_ version to compare to, and nothing
>> but 2.21.0 would really serve that role satisfactorily.  Particularly
>> where problems are detected a long time after getting introduced, having
>> an installable version as a reference is nice, and "it stopped working
>> in 2.21.0" is enough of a quagmire already that we do not really want to
>> add a lot more here.
>
> Sounds good (well, Python 3 is already in). To be sure: This also means
> we'll be using GUB for 2.21.0? I'd like to propose a new system (yes,
> *with* support for Windows) soon, but not sure that I can make it in
> the next week or so...

Yes, GUB for 2.21.0.  We don't want to have another indeterminate
backlog on unstable releases.  That means that GUB needs to get switched
over to Python 3.  It may make it more prudent, should we need to
release 2.20.1 at some time, to also go to the cherry-picking nightmare
required to bring stable/2.20 up to Python 3.  Definitely a holdup I
would not have wanted for 2.20.0.

If we want to switch over to a different release method, we can do that
comfortably without unstable releases being blocked.  Whether we want to
eventually bring out a 2.20 version in that manner too (which might
bring different platform support) or save it for 2.22 or whenever is
something I don't think we should try pinning down now.

>> The size of the headache basically is commensurate with how long the
>> stable branch has diverged.  Hopefully we manage to find some
>> combination of process and responsible persons next time around that
>> delivers faster.
>
> To throw this idea onto the mailing list: Time-based releases seem to
> encourage a predictable schedule. I don't think it makes sense to have
> monthly stable releases as, for example, GitLab does. But maybe
> tracking something like once in a year to 18 months with defined
> windows for alpha and beta releases?

We have to see how this pans out.  The last release cycle saw something
like a half-year blockage due to GUB problems.  It's not like anybody
wanted this to keep up for as long as it did.  And there is no point in
committing to schedules if there are no persons tied into the
commitment.  It's not like I didn't offer the release manager job for
grabs several times round with no takers.  Committing to regular
schedules with me as sole release manager candidate is a predictable
setup for disappointment.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

Jonas Hahnfeld
Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup:

> Jonas Hahnfeld <
> [hidden email]
> > writes:
>
> > Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> > > Ok, I think 2.20 is basically done and we should push it out by the end
> > > of this week.  This leaves a few days for the translation team to catch
> > > up with the current state.
> >
> > Wohoo!
> >
> > > [...]
> > >
> > > What does this mean for 2.21.0?  I think we should aim to push it out
> > > fast afterwards, basically a few days later at most, just to get kinks
> > > with webpage/versioning from 2.20 ironed out.
> > >
> > > [...]
> > >
> > > For more extensive changes of internals and/or syntax, I would recommend
> > > to let them sit till 2.21.1 before committing, assuming that we _do_
> > > manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
> > > significantly diverged from 2.20.0.  If something does not quite work,
> > > it would be nice to have a _released_ version to compare to, and nothing
> > > but 2.21.0 would really serve that role satisfactorily.  Particularly
> > > where problems are detected a long time after getting introduced, having
> > > an installable version as a reference is nice, and "it stopped working
> > > in 2.21.0" is enough of a quagmire already that we do not really want to
> > > add a lot more here.
> >
> > Sounds good (well, Python 3 is already in). To be sure: This also means
> > we'll be using GUB for 2.21.0? I'd like to propose a new system (yes,
> > *with* support for Windows) soon, but not sure that I can make it in
> > the next week or so...
>
> Yes, GUB for 2.21.0.  We don't want to have another indeterminate
> backlog on unstable releases.  That means that GUB needs to get switched
> over to Python 3.
For those following along: It's not that we need to convert GUB to
Python 3, just switch the dependencies of the LilyPond spec.

> It may make it more prudent, should we need to
> release 2.20.1 at some time, to also go to the cherry-picking nightmare
> required to bring stable/2.20 up to Python 3.

My point of view remains: Just keep an old version of GUB around and
we're fine for 2.20.x, x > 0.

Jonas

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

dak
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup:
>
>> Yes, GUB for 2.21.0.  We don't want to have another indeterminate
>> backlog on unstable releases.  That means that GUB needs to get switched
>> over to Python 3.
>
> For those following along: It's not that we need to convert GUB to
> Python 3, just switch the dependencies of the LilyPond spec.
>
>> It may make it more prudent, should we need to
>> release 2.20.1 at some time, to also go to the cherry-picking nightmare
>> required to bring stable/2.20 up to Python 3.
>
> My point of view remains: Just keep an old version of GUB around and
> we're fine for 2.20.x, x > 0.

In the end, it will depend on how it works out for the person creating
the releases, I guess.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [translations] 2.20 and 2.21 release plans

Jean-Charles Malahieude-2
In reply to this post by dak
Le 17/02/2020 à 13:25, David Kastrup a écrit :

>
> Ok, I think 2.20 is basically done and we should push it out by the end
> of this week.  This leaves a few days for the translation team to catch
> up with the current state.
>
> In particular HINT HINT HINT it gives the opportunity to native speakers
> of languages not as meticulously maintained as the currently most active
> translations to at least tackle the Changes document and maybe check a
> few other points of the web presence.  This is more addressed to people
> reading this announcement on the lilypond-devel list than to lurkers on
> the translations list, though of course the latter would be equally
> welcome.
>

I've planned to merge translation into stable on Thursday night, with
the French part fully updated (lots of work with Werner's indexing).

Cheers,
--
Jean-Charles

dak
Reply | Threaded
Open this post in threaded view
|

Re: [translations] 2.20 and 2.21 release plans

dak
Jean-Charles Malahieude <[hidden email]> writes:

> Le 17/02/2020 à 13:25, David Kastrup a écrit :
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week.  This leaves a few days for the translation team to catch
>> up with the current state.
>> In particular HINT HINT HINT it gives the opportunity to native
>> speakers
>> of languages not as meticulously maintained as the currently most active
>> translations to at least tackle the Changes document and maybe check a
>> few other points of the web presence.  This is more addressed to people
>> reading this announcement on the lilypond-devel list than to lurkers on
>> the translations list, though of course the latter would be equally
>> welcome.
>>
>
> I've planned to merge translation into stable on Thursday night, with
> the French part fully updated (lots of work with Werner's indexing).

That sounds great.  Well yes, the indexing changes have been very recent
and pretty large.  If anybody else feels like their work would benefit
from a minor delay, please speak up.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [translations] 2.20 and 2.21 release plans

Federico Bruni-2


Il giorno lun 17 feb 2020 alle 22:35, David Kastrup <[hidden email]> ha
scritto:

> Jean-Charles Malahieude <[hidden email]> writes:
>
>>  Le 17/02/2020 à 13:25, David Kastrup a écrit :
>>>  Ok, I think 2.20 is basically done and we should push it out by the
>>>  end
>>>  of this week.  This leaves a few days for the translation team to
>>> catch
>>>  up with the current state.
>>>  In particular HINT HINT HINT it gives the opportunity to native
>>>  speakers
>>>  of languages not as meticulously maintained as the currently most
>>> active
>>>  translations to at least tackle the Changes document and maybe
>>> check a
>>>  few other points of the web presence.  This is more addressed to
>>> people
>>>  reading this announcement on the lilypond-devel list than to
>>> lurkers on
>>>  the translations list, though of course the latter would be equally
>>>  welcome.
>>>
>>
>>  I've planned to merge translation into stable on Thursday night,
>> with
>>  the French part fully updated (lots of work with Werner's indexing).
>
> That sounds great.  Well yes, the indexing changes have been very
> recent
> and pretty large.  If anybody else feels like their work would benefit
> from a minor delay, please speak up.
>

I'm working on the italian update and I hope to be ready before
Thursday night.




Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

Urs Liska-3
In reply to this post by dak
Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the
> end
> of this week.  

This is really great news!
I'm somewhat undecided whether it is a cause for celebration or not to
finally release a "stable" version after six years. But at the end of
the day I think we should praise those who have actually worked so hard
to make it happen. And all of us who benefit from that work might think
about what we can do to help bringing the *next* stable release over
the goal line in less than six years.

I have one side remark to that, although I'm not sure if it's
appropriate to inject it into this thread.

I haven't commented on the issue of a package loading mechanism
recently, for two reasons: I don't have any time right now, and I
thought it would be a distraction from the more pressing issues around
the build system, contribution workflow/tooling and finalizing a
release.
While it has been clear from the start that integrating a package
loading mechanism was not in question for 2.20.0, I would like to ask
if it can be considered making this go into a 2.20.x release and not
keep it on the 2.21 track as would be the natural itinerary. Doing so
(the latter) would force openLilyLib and - more importantly -
interfaces like Frescobaldi to support two alternative syntaxes of
loading packages until a 2.22 release.
So I would be glad if we could spend sufficient effort after 2.20.0 and
2.21.0 releases to discussing, implementing, and testing a package
loading mechansim sufficiently that we can integrate it not only in the
2.21.x but also a 2.20.x release.

Urs

> This leaves a few days for the translation team to catch
> up with the current state.
>
> In particular HINT HINT HINT it gives the opportunity to native
> speakers
> of languages not as meticulously maintained as the currently most
> active
> translations to at least tackle the Changes document and maybe check
> a
> few other points of the web presence.  This is more addressed to
> people
> reading this announcement on the lilypond-devel list than to lurkers
> on
> the translations list, though of course the latter would be equally
> welcome.
>
> What does this mean for 2.21.0?  I think we should aim to push it out
> fast afterwards, basically a few days later at most, just to get
> kinks
> with webpage/versioning from 2.20 ironed out.
>
> I am not sure it is realistic to expect to get the translations
> merged
> into 2.21.0 already: because of the significant divergence
> experienced
> so far, I expect this to be a significant merging headache.  It would
> be
> nice to have, but not essential: this is the unstable branch after
> all.
>
> For more extensive changes of internals and/or syntax, I would
> recommend
> to let them sit till 2.21.1 before committing, assuming that we _do_
> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
> significantly diverged from 2.20.0.  If something does not quite
> work,
> it would be nice to have a _released_ version to compare to, and
> nothing
> but 2.21.0 would really serve that role satisfactorily.  Particularly
> where problems are detected a long time after getting introduced,
> having
> an installable version as a reference is nice, and "it stopped
> working
> in 2.21.0" is enough of a quagmire already that we do not really want
> to
> add a lot more here.
>
> The size of the headache basically is commensurate with how long the
> stable branch has diverged.  Hopefully we manage to find some
> combination of process and responsible persons next time around that
> delivers faster.
>
> Nevertheless, I am glad we are getting there.
>


dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20 and 2.21 release plans

dak
Urs Liska <[hidden email]> writes:

> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week.  
>
> This is really great news!
> I'm somewhat undecided whether it is a cause for celebration or not to
> finally release a "stable" version after six years. But at the end of
> the day I think we should praise those who have actually worked so hard
> to make it happen. And all of us who benefit from that work might think
> about what we can do to help bringing the *next* stable release over
> the goal line in less than six years.
>
> I have one side remark to that, although I'm not sure if it's
> appropriate to inject it into this thread.
>
> I haven't commented on the issue of a package loading mechanism
> recently, for two reasons: I don't have any time right now, and I
> thought it would be a distraction from the more pressing issues around
> the build system, contribution workflow/tooling and finalizing a
> release.
> While it has been clear from the start that integrating a package
> loading mechanism was not in question for 2.20.0, I would like to ask
> if it can be considered making this go into a 2.20.x release and not
> keep it on the 2.21 track as would be the natural itinerary. Doing so
> (the latter) would force openLilyLib and - more importantly -
> interfaces like Frescobaldi to support two alternative syntaxes of
> loading packages until a 2.22 release.
> So I would be glad if we could spend sufficient effort after 2.20.0 and
> 2.21.0 releases to discussing, implementing, and testing a package
> loading mechansim sufficiently that we can integrate it not only in the
> 2.21.x but also a 2.20.x release.

I don't think that would make a lot of sense since 2.21.x is the test
and maturing bed for 2.22.

But there is nobody forcing us to take 6 years for 2.22.  Or 3.0.  A
fully functional package organisation system would in my opinion justify
a major version number change.  Also it does look like the next stable
release is going to contain Guile 2+ support that is less of an
abomination than what we have so far been able to provide.

At any rate, I don't think it makes sense to nail down too many
specifics of unreleased versions.  Not if we want to end up more timely
than this time round.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: [translations] 2.20 and 2.21 release plans

Federico Bruni-2
In reply to this post by Jean-Charles Malahieude-2


Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
<[hidden email]> ha scritto:

>
>
> Il giorno lun 17 feb 2020 alle 22:35, David Kastrup <[hidden email]> ha
> scritto:
>> Jean-Charles Malahieude <[hidden email]> writes:
>>
>>>  Le 17/02/2020 à 13:25, David Kastrup a écrit :
>>>>  Ok, I think 2.20 is basically done and we should push it out by
>>>> the
>>>>  end
>>>>  of this week.  This leaves a few days for the translation team to
>>>> catch
>>>>  up with the current state.
>>>>  In particular HINT HINT HINT it gives the opportunity to native
>>>>  speakers
>>>>  of languages not as meticulously maintained as the currently most
>>>> active
>>>>  translations to at least tackle the Changes document and maybe
>>>> check a
>>>>  few other points of the web presence.  This is more addressed to
>>>> people
>>>>  reading this announcement on the lilypond-devel list than to
>>>> lurkers on
>>>>  the translations list, though of course the latter would be
>>>> equally
>>>>  welcome.
>>>>
>>>
>>>  I've planned to merge translation into stable on Thursday night,
>>> with
>>>  the French part fully updated (lots of work with Werner's
>>> indexing).
>>
>> That sounds great.  Well yes, the indexing changes have been very
>> recent
>> and pretty large.  If anybody else feels like their work would
>> benefit
>> from a minor delay, please speak up.
>>
>
> I'm working on the italian update and I hope to be ready before
> Thursday night.
>

Can we have one day delay? So deadline to push to translation branch by
Friday night?
I guess I won't have enough time to complete the update but at least I
can use some spare time tomorrow to get close to the goal.




dak
Reply | Threaded
Open this post in threaded view
|

2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)

dak
Federico Bruni <[hidden email]> writes:

> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
> <[hidden email]> ha scritto:

>> I'm working on the italian update and I hope to be ready before
>> Thursday night.
>>
>
> Can we have one day delay? So deadline to push to translation branch
> by Friday night?
> I guess I won't have enough time to complete the update but at least I
> can use some spare time tomorrow to get close to the goal.

There was no fixed deadline.  My goal was "this weekend", but if that
makes things ugly, there is no point in not delaying some more days
after the years we spent on this.

In unrelated news, I tried my hand at translating at least the Changes
file into German and am about 50% done.  Anybody want to work from the
bottom so that we should coordinate in order to avoid duplicate effort?
I got kind of a headache so far.  Hats off to people who tackle a whole
translation rather than just a puny file.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.20.0 release coordination with translation, also Germans? (was: [translations] 2.20 and 2.21 release plans)

Federico Bruni-2
Il giorno gio 20 feb 2020 alle 14:06, David Kastrup <[hidden email]> ha
scritto:
> In unrelated news, I tried my hand at translating at least the Changes
> file into German and am about 50% done.  Anybody want to work from the
> bottom so that we should coordinate in order to avoid duplicate
> effort?
> I got kind of a headache so far.  Hats off to people who tackle a
> whole
> translation rather than just a puny file.

Indeed, it requires a strong commitment... it took me almost 10 years
to translate all the manuals!

Translation infrastructure is another area which could be improved.
After 2.20 is out I'll try to bring it up for discussion.




dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20.0 release coordination with translation, also Germans?

dak
Federico Bruni <[hidden email]> writes:

> Il giorno gio 20 feb 2020 alle 14:06, David Kastrup <[hidden email]> ha
> scritto:
>> In unrelated news, I tried my hand at translating at least the Changes
>> file into German and am about 50% done.  Anybody want to work from the
>> bottom so that we should coordinate in order to avoid duplicate
>> effort?
>> I got kind of a headache so far.  Hats off to people who tackle a
>> whole
>> translation rather than just a puny file.
>
> Indeed, it requires a strong commitment... it took me almost 10 years
> to translate all the manuals!
>
> Translation infrastructure is another area which could be improved.
> After 2.20 is out I'll try to bring it up for discussion.

I could not actually get any script to do anything helpful.  I remember
this being different at some point of time in the past.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: [translations] Re: 2.20.0 release coordination with translation, also Germans?

Federico Bruni-2
Il giorno gio 20 feb 2020 alle 15:21, David Kastrup <[hidden email]> ha
scritto:
> I could not actually get any script to do anything helpful.  I
> remember
> this being different at some point of time in the past.

I use `make check-translation` regularly and has always worked.
But you should be aware that:

1. you must run it in the Documentation/ dir
2. if you've configured an out-of-tree build (very likely as you are a
developer), you'll probably get problems. So I think you should
download the translation branch in a separate clean directory.




dak
Reply | Threaded
Open this post in threaded view
|

2.20.0 release coordination with translation. Other showstoppers? (was: 2.20.0 release coordination with translation, also Germans?)

dak
In reply to this post by dak
David Kastrup <[hidden email]> writes:

> Federico Bruni <[hidden email]> writes:
>
>> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
>> <[hidden email]> ha scritto:
>
>>> I'm working on the italian update and I hope to be ready before
>>> Thursday night.
>>>
>>
>> Can we have one day delay? So deadline to push to translation branch
>> by Friday night?
>> I guess I won't have enough time to complete the update but at least I
>> can use some spare time tomorrow to get close to the goal.
>
> There was no fixed deadline.  My goal was "this weekend", but if that
> makes things ugly, there is no point in not delaying some more days
> after the years we spent on this.
>
> In unrelated news, I tried my hand at translating at least the Changes
> file into German and am about 50% done.  Anybody want to work from the
> bottom so that we should coordinate in order to avoid duplicate effort?
> I got kind of a headache so far.  Hats off to people who tackle a whole
> translation rather than just a puny file.

German Changes file has been added by now.  Where are we with regard to
the other translations?  Federico?

The plan for afterwards would generally be that we
merge/move/cherrypick/whatever translations into master without
introducing unintended regressions.  I may try doing that as I am
probably most at fault for the long 2.19.80+ phase.  For changes to doc
and translation afterwards, it will make sense to check individually
whether they can/should also go by cherry-picking into the stable branch
for the sake of possible 2.20 followup releases.  The main criterion
obviously being whether they refer to functionality actually present in
2.20.

So there is a bit of leeway for improvements in the 2.20 documentation
even after the 2.20.0 line.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.20.0 release coordination with translation. Other showstoppers? (was: 2.20.0 release coordination with translation, also Germans?)

Federico Bruni-2
Il giorno sab 22 feb 2020 alle 19:25, David Kastrup <[hidden email]> ha
scritto:
> German Changes file has been added by now.  Where are we with regard
> to
> the other translations?  Federico?

I'm still working on it.
My spare time is limited and the changes by Werner requires a lot of
meticulous edits.

If you want to release tomorrow, let me know and I'll push tonight what
I manage to do. Then the rest of the update might be included in 2.20.2.
Or, if you prefer waiting for the whole italian update, I will advise
when I've completed it. I cannot say now how long it will take exactly.
Probably not before tomorrow night.




dak
Reply | Threaded
Open this post in threaded view
|

Re: 2.20.0 release coordination with translation. Other showstoppers?

dak
Federico Bruni <[hidden email]> writes:

> Il giorno sab 22 feb 2020 alle 19:25, David Kastrup <[hidden email]> ha
> scritto:
>> German Changes file has been added by now.  Where are we with regard
>> to
>> the other translations?  Federico?
>
> I'm still working on it.
> My spare time is limited and the changes by Werner requires a lot of
> meticulous edits.
>
> If you want to release tomorrow, let me know and I'll push tonight
> what I manage to do. Then the rest of the update might be included in
> 2.20.2.
> Or, if you prefer waiting for the whole italian update, I will advise
> when I've completed it. I cannot say now how long it will take
> exactly. Probably not before tomorrow night.

My principle plan would be to tell Phil to go ahead (after receiving the
last OK from people doing last-minute work) at a point of time where he
thinks he may be somewhat responsive in the followup days, just in case
something hits the fan.

One interesting consideration is that the VERSION file upon release
should look like

PACKAGE_NAME=LilyPond
MAJOR_VERSION=2
MINOR_VERSION=20
PATCH_LEVEL=0
MY_PATCH_LEVEL=
VERSION_STABLE=2.20.0
VERSION_DEVEL=2.20.0

basically announcing the same versions as stable and unstable since
2.20.0 will both be the latest stable release as well as the latest
release altogether.  Things will normalise once we get a followup
unstable release.

I seem to remember that if we declared VERSION_DEVEL to point to a yet
unreleased 2.21.0, the links would essentially end up dead.

So there are little quirks like that accompanying a stable release that
might cause followup work.  So "last day of weekend" sounds only
sensible if Phil is not considerably unavailable afterwards.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: [translations] Re: 2.20.0 release coordination with translation. Other showstoppers?

Federico Bruni-2
Il giorno sab 22 feb 2020 alle 23:54, David Kastrup <[hidden email]> ha
scritto:
> My principle plan would be to tell Phil to go ahead (after receiving
> the
> last OK from people doing last-minute work) at a point of time where
> he
> thinks he may be somewhat responsive in the followup days, just in
> case
> something hits the fan.

Ok, then I pushed to translation branch my work so far.
I guess I'll push the final update on Monday.




Reply | Threaded
Open this post in threaded view
|

Re: 2.20.0 release coordination with translation. Other showstoppers?

Francisco Vila
In reply to this post by dak
El 22/2/20 a las 19:25, David Kastrup escribió:
> So there is a bit of leeway for improvements in the 2.20 documentation
> even after the 2.20.0 line.

Good. I am late, sorry. But I'll hopefully sync Doc-es in a few days.

--
Francisco Vila, Ph.D. - Badajoz (Spain)
paconet.org , lilypond.es

12