On Tue, Jun 21, 2011 at 2:55 PM, Bruno Winck <bw@...2632...> wrote:
Say you are December 23rd this year. 11.12 was done on December 1rst. The last bugfix of the year necessary due to some library bug. It can't be completed this day, everyone leaves until January 1rst. It is released January 2nd. Waiting behind the major release everyone has been working on. How do you name this bugfix ?
12.01 11.12 2011.8 (8th bug fix) 2011.h 11.13 11.12b
12.01
Last time someone suggest me shortening dates was back in 1985, to save 2 octets for each date. That was a trick a friend gave me, insider advice. So 1985 became 85, who could believe the program would survive the hardware. So hopes and virtuous release cycle are nice but IMO it is better to first reach such cycles and then enforce it in names. Otherwise it may fire back.
There's nothing to backfire. The reality is that it won't be enforcing release cycles by name. Given that I've been the only steady release warden for the past few years *shudder*, I'm cracking down on our release policy. I need to put together a proposed release schedule. But the loose version is as such...
*Here in about a few days I set forth the dates for this schedule... *We release in hopefully October or November (we have a lot of changes this cycle to be watched and tested). *Just after release, I set forth the next schedule, which includes a bug-fix release to the stable branch 3 months out (planned, not to say we won't push one earlier). The synchronization of releases will most likely be planned so that our bugfix releases are the ones that get picked up by distros (this needs to be discussed). *Repeat the cycle (minus my current guesstimate) once the next "new" release makes it out.
Basically, we'll just change policy to "if a new feature is not ready enough, wait out a release cycle as it will be 6-months to tighten up that feature". This is a needed change as we seem to get people starting work in trunk and not finishing it, this is very bad practice.
This may mean we may end up with a 3rd branch for experimental features (where devs want things tested as they're writing), or that aren't otherwise in good enough shape for trunk. So, it may end up looking like "stable", "trunk", & "experimental" to still achieve continuous development. Note, a bonus to us doing this would have gotten the cairo stuff merged into "experimental" much earlier for more testing. This all needs to be discussed and a group consensus of the most active developers & testers is needed before any such changes would be made.
I guess the issue is that Inkscape is a pretty mature project now and we need to do some things to prevent repeating mistakes of the past... release frequency and development habits being two of those trouble areas.
I hope to see Inkscape around on 2111 :)
I won't likely be alive in 2111. ;) Besides, if Inkscape is around in 2111 in some form, I think it will just be called Inkscape and whatever computers will just magically keep it all up to date for you... and draw what you see in your head for you as well. ;)
Cheers, Josh