Re: Post-2.12 release plans
Le lundi 22 décembre 2008 à 11:23 -0800, Graham Percival a écrit : > This is totally a meritocracy question. Non-developers want the > sun and moon, right now, for the price of a download. So, let's ask for a fee for each download -<:o) > In the past we've tried to do the backporting idea. It's lasted > for a few months, but then we just abandon the stable branch. > When complicated changes happen -- for example, the vertical > collision avoidance -- it gets to be too much work to backport > stuff. I'm therefore invoking whatever veto power I have on this > particular discussion. Backporting is not something that I can do > or teach; in the past it hasn't worked; Indeed: the backporting I did for one or 2 months surprised many people, even our support guru Mats :-) and the only little fun I had with this was playing with Git I had just discovered. > in the absence of a > knowledgeable person who is willing to spend whatever amount of > time it takes, this isn't an option. Agreed. Let's spend time on more important tasks. > I'm convinced that the docs/website/support can handle this type > of devel cycle without problems; the only question is whether > developers are on board, and currently this sounds promising. I'm confident too. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
On Mon, Dec 22, 2008 at 06:54:43PM -, Trevor Daniels wrote: > > Han-Wen Nienhuys wrote Monday, December 22, 2008 6:22 PM > >> It would be really nice if we could invert the rhythms of >> stable/devel: have a long stable cycle with many releases (like 2.11 >> had), and thenhave a flurry of 2.13 releases which introduce >> incompatibilities, and push out 2.14 asap. That's my hope -- but it depends on what kinds of syntax-changing patches people want to merge. We don't want to slow down development too much. > I'm still not sold on the benefits of this. There are many users who do not > want a changing environment - the ones that are still on 2.10, for example. > If we go along with this, there will be no uniform stable environment. Even > if each of these users just downloads a single version and sticks with that, > they may choose different versions, which means they have different > documentation and different features. That complicates discussion and > help on -user. It also makes keeping the documentation in synch more > difficult. That doesn't matter in a release clearly tagged as > "development", > but it does matter in a release tagged as stable. Minor issue compared to 2.10 vs. 2.11. We've really only had a single branch for the past year or more, and it's worked fine for people on 2.11. The only support problems we've had with 2.11 were the newbies using 2.11 and syntax changes, but if 2.12 has no syntax changes that won't be an issue. (and with an active stable branch, there's less pressure for newbies to wander into devel territory) > I still think the benefits of a truly stable release for those users who > simply want to engrave music should not be discarded lightly. So far > this discussion has been limited to the -devel list. Should we not seek > opinion on-user? oh god no. (I'm so shocked I forgot to insert "Mao" in that. :) This is totally a meritocracy question. Non-developers want the sun and moon, right now, for the price of a download. In the past we've tried to do the backporting idea. It's lasted for a few months, but then we just abandon the stable branch. When complicated changes happen -- for example, the vertical collision avoidance -- it gets to be too much work to backport stuff. I'm therefore invoking whatever veto power I have on this particular discussion. Backporting is not something that I can do or teach; in the past it hasn't worked; in the absence of a knowledgeable person who is willing to spend whatever amount of time it takes, this isn't an option. I'm convinced that the docs/website/support can handle this type of devel cycle without problems; the only question is whether developers are on board, and currently this sounds promising. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
Han-Wen Nienhuys wrote Monday, December 22, 2008 6:22 PM On Mon, Dec 22, 2008 at 10:58 AM, Graham Percival wrote: Does this mean you do not want to make any difference between odd and even versions? No. .13 would be the "devel" version, where syntax changes are introduced, and any major breakage occurs. It would last as long as necessary to fix the major breakage and everybody to get their syntax changes introduced. Then .14 would be released. Ideally, I'd shoot for 6 months of .12, 2 months of .13, then .14. I mean, if there's no syntax changes and no major breakage, then there's no point stopping .12 and calling it .13. Now, 6 months without syntax changes is probably a bit long at this point, so .12 might only be 3 months. But hopefully .14 or .16 could have a longer stable branch. It would be really nice if we could invert the rhythms of stable/devel: have a long stable cycle with many releases (like 2.11 had), and thenhave a flurry of 2.13 releases which introduce incompatibilities, and push out 2.14 asap. I'm still not sold on the benefits of this. There are many users who do not want a changing environment - the ones that are still on 2.10, for example. If we go along with this, there will be no uniform stable environment. Even if each of these users just downloads a single version and sticks with that, they may choose different versions, which means they have different documentation and different features. That complicates discussion and help on -user. It also makes keeping the documentation in synch more difficult. That doesn't matter in a release clearly tagged as "development", but it does matter in a release tagged as stable. I still think the benefits of a truly stable release for those users who simply want to engrave music should not be discarded lightly. So far this discussion has been limited to the -devel list. Should we not seek opinion on-user? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
On Mon, Dec 22, 2008 at 10:58 AM, Graham Percival wrote: >> Does this mean you do not want to make any difference between odd and >> even versions? > > No. .13 would be the "devel" version, where syntax changes are > introduced, and any major breakage occurs. It would last as long > as necessary to fix the major breakage and everybody to get their > syntax changes introduced. Then .14 would be released. > > Ideally, I'd shoot for 6 months of .12, 2 months of .13, then .14. > I mean, if there's no syntax changes and no major breakage, then > there's no point stopping .12 and calling it .13. Now, 6 months > without syntax changes is probably a bit long at this point, so > .12 might only be 3 months. But hopefully .14 or .16 could have a > longer stable branch. It would be really nice if we could invert the rhythms of stable/devel: have a long stable cycle with many releases (like 2.11 had), and thenhave a flurry of 2.13 releases which introduce incompatibilities, and push out 2.14 asap. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
Graham Percival wrote Monday, December 22, 2008 5:40 AM Once 2.12 is out and we've succeeded in setting up GUB3 on kainhofer, I'll become the Release Manager. I have two ideas on how to change things: 1) Move to a linux kernel type of releases: instead of having separate devel and stable branches, we just do everything in 2.12. In some ways, we've been doing this already; we haven't touched 2.10 in quite a while. 2) Keep the distinction between stable and devel, but tie it to the input syntax, and allow for much faster releases. In particular, there would be *no* convert-ly rules for 2.12. New constructs would be fine, but any patches that would change existing syntax would be delayed until 2.13. I'm not sure I go along with this. The main point about the stable even-numbered releases is that they are *stable*. If "permitting new constructs" implies permitting new features and new code, then the release is potentially unstable. I would prefer changes in even-numbered releases to be limited to bug-fixing, and even bug-fixes with significant code changes should be deferred to a development release. In the past we've avoided this kind of policy since it slows down development, but my proposal is to have /much/ faster development cycles. Maybe something like 3 months of 2.12 releases, then 2 months of 2.13 releases (including the delayed syntax changes), and then 2.14. Then we'd repeat it again. I agree stable releases should be made more frequently. But I don't see why spinning off a stable release impedes the development process. Can't the stable release be contained in a separate branch? Or am I missing something? Cheers, - Graham Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
On Mon, Dec 22, 2008 at 12:56:35PM +0100, Valentin Villenave wrote: > 2008/12/22 Graham Percival : > > Once 2.12 is out and we've succeeded in setting up GUB3 on > > kainhofer, I'll become the Release Manager. I have two ideas on > > how to change things: > > Good to see you're still involved, Mr > "I'm-leavin'-soon-anyway-so-just-pretend-I'm-not-here" :-) It's a good exercise. Besides, I don't think I touched git in the past four months, so you could certainly argue that I *wasn't* here. > > 2) Keep the distinction between stable and devel, but tie it to > > the input syntax, and allow for much faster releases. In > > particular, there would be *no* convert-ly rules for 2.12. New > > constructs would be fine, but any patches that would change > > existing syntax would be delayed until 2.13. > > Hm, let's not be too strict in advance. No "major" breakage in 2.12 is > already a sensible goal; no syntax change at all... well, there's > always the possibility that we have to correct some inconsistency we > may have missed until now, or whatever. Under this scheme, that inconsistency would remain un-committed for two or three months. I suggest that this isn't too horrible, and it would be worth it for the increased stability. When I say "stability", I don't care about complaints on -user (obviously; I'm still me :). I'm talking about projects like rosegarden or Strasheela -- I'd *love* to be able to say "if your software exports a well-formed file for 2.12, it will work in all 2.12 versions. If you want to compile it in 2.14 or later, then you'll need to run it through convert-ly or update your export function". > > Yes, this would mean that some patches would be delayed a few > > months, but with git it's easier to test them in separate > > branches. We'd also be flexible about when to start 2.13 -- if > > there was a great new feature that required changing the existing > > syntax, we could start .13 earlier than 3 months. Conversely, if > > all development is simply adding new features or fixing bugs, we > > don't start .13 until later. > > Does this mean you do not want to make any difference between odd and > even versions? No. .13 would be the "devel" version, where syntax changes are introduced, and any major breakage occurs. It would last as long as necessary to fix the major breakage and everybody to get their syntax changes introduced. Then .14 would be released. Ideally, I'd shoot for 6 months of .12, 2 months of .13, then .14. I mean, if there's no syntax changes and no major breakage, then there's no point stopping .12 and calling it .13. Now, 6 months without syntax changes is probably a bit long at this point, so .12 might only be 3 months. But hopefully .14 or .16 could have a longer stable branch. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
2008/12/22 Graham Percival : > Once 2.12 is out and we've succeeded in setting up GUB3 on > kainhofer, I'll become the Release Manager. I have two ideas on > how to change things: Good to see you're still involved, Mr "I'm-leavin'-soon-anyway-so-just-pretend-I'm-not-here" :-) > 2) Keep the distinction between stable and devel, but tie it to > the input syntax, and allow for much faster releases. In > particular, there would be *no* convert-ly rules for 2.12. New > constructs would be fine, but any patches that would change > existing syntax would be delayed until 2.13. Hm, let's not be too strict in advance. No "major" breakage in 2.12 is already a sensible goal; no syntax change at all... well, there's always the possibility that we have to correct some inconsistency we may have missed until now, or whatever. > In the past we've avoided this kind of policy since it slows down > development, but my proposal is to have /much/ faster development > cycles. Maybe something like 3 months of 2.12 releases, then 2 > months of 2.13 releases (including the delayed syntax changes), > and then 2.14. Then we'd repeat it again. Actually, not having to backport anything from 2.13 to 2.12 might also make development move faster. > Yes, this would mean that some patches would be delayed a few > months, but with git it's easier to test them in separate > branches. We'd also be flexible about when to start 2.13 -- if > there was a great new feature that required changing the existing > syntax, we could start .13 earlier than 3 months. Conversely, if > all development is simply adding new features or fixing bugs, we > don't start .13 until later. Does this mean you do not want to make any difference between odd and even versions? Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Post-2.12 release plans
On Mon, Dec 22, 2008 at 3:40 AM, Graham Percival wrote: > Once 2.12 is out and we've succeeded in setting up GUB3 on > kainhofer, I'll become the Release Manager. I have two ideas on > how to change things: > > 1) Move to a linux kernel type of releases: instead of having > separate devel and stable branches, we just do everything in 2.12. > In some ways, we've been doing this already; we haven't touched > 2.10 in quite a while. > > 2) Keep the distinction between stable and devel, but tie it to > the input syntax, and allow for much faster releases. In > particular, there would be *no* convert-ly rules for 2.12. New > constructs would be fine, but any patches that would change > existing syntax would be delayed until 2.13. Sounds like an excellent idea - I would exempt changes introduced after 2.12.0 from the no syntax changes, though. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Post-2.12 release plans
Once 2.12 is out and we've succeeded in setting up GUB3 on kainhofer, I'll become the Release Manager. I have two ideas on how to change things: 1) Move to a linux kernel type of releases: instead of having separate devel and stable branches, we just do everything in 2.12. In some ways, we've been doing this already; we haven't touched 2.10 in quite a while. 2) Keep the distinction between stable and devel, but tie it to the input syntax, and allow for much faster releases. In particular, there would be *no* convert-ly rules for 2.12. New constructs would be fine, but any patches that would change existing syntax would be delayed until 2.13. In the past we've avoided this kind of policy since it slows down development, but my proposal is to have /much/ faster development cycles. Maybe something like 3 months of 2.12 releases, then 2 months of 2.13 releases (including the delayed syntax changes), and then 2.14. Then we'd repeat it again. Yes, this would mean that some patches would be delayed a few months, but with git it's easier to test them in separate branches. We'd also be flexible about when to start 2.13 -- if there was a great new feature that required changing the existing syntax, we could start .13 earlier than 3 months. Conversely, if all development is simply adding new features or fixing bugs, we don't start .13 until later. Thoughts? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
