Re: survey on multiple development versions

[Curt]

I wonder if this is coming across more confusing than it has to be.  You're 
talking about branching a "feature branch" from the mainline (probably the 
development branch: 2.17.24, 2.17.25, etc)  and merging from it (as the 
mainline changes), while the feature branch is improved, until the feature 
branch is stable enough to merge it back into the mainline.

If the feature branch isn't yet stable enough to make a big release like 2.18, 
then no problem, keep it separate and continue to merge from the mainline until 
it's ready, and then merge it back to the mainline.

If new changes are made to the mainline that are inherently incompatible with 
the feature branch, then switch approaches by considering the feature branch as 
a temporary fork.  Instead of merging from the mainline, instead merge from the 
various smaller feature branches that are also merged into the mainline, that 
aren't incompatible with the feature branch.  In other words, if someone wants 
to make a change to the mainline, they do it in their own branch - and then 
when it comes time to contribute it back to the mainline, the fork branch 
accepts it as well.  If there isn't a way to set up this process easily, you 
could probably do this alternatively by doing selective merges from the 
mainline into the feature branch.

From the perspective of the mainline, it doesn't care because it's not being 
negatively affected, and it doesn't limit its release schedule.  It doesn't 
care what is being pulled from it, it only cares what is being pushed to it.  
From the perspective of the fork branch, it has the time to get stable before 
it gets re-integrated back into the mainline.

From the perspective of the user, it isn't as complicated as them having A B 
and C all seeming equally valid and confusing.  There's the release (2.18, 
2.19, etc), the development line, and if they want one of these experimental 
branches they have to use one of the forked releases - I would expect that 
these types of users would be pretty savvy about keeping track of the 
differences, and perhaps able to build binaries themselves.

Curt

On Dec 10, 2013, at 5:23 AM, Mike Solomon <address@hidden> wrote:

> Hey all,
> 
> I recently e-mailed the development list about multiple concurrent 
> development versions and I’d like to ask users, especially those currently 
> using the development version, to take the time to respond to a question 
> regarding the proposal.
> 
> If lilypond.org were to propose multiple development versions (say 5 instead 
> of 1), each offering a different set of experimental features (including the 
> canonical development version), and if lilypond.org offered information on 
> which versions were in need of testing by what types of users, would you be 
> interested in helping out by doing some typesetting with these alternative 
> versions?
> 
> Cheers,
> MS
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user