On Thu, 2 Dec 2004, MenTaLguY wrote:
On Thu, 2 Dec 2004, Kees Cook wrote:
I support this method. It also gives us the option (if we can create a tight packaging cycle) to put major bug fixes (that don't require architectural changes) into a stable release. For example, we have 0.40.0 now, and now we're working on 0.41.0. If the libgc problems could be solved via some secret tunable we discover next week, we could put it into 0.40.1, and release it while also putting it into 0.41.0 development. All standard release branching.
I think what's held this up in the past as been just lack of testing/packaging time to deal with making modifications to the tagged release branch.
Don't forget that we actually did that for 0.39.1.
However, I do tend to agree with bulia that it'd be best to avoid an 0.40.1 release specifically, because of existing strong expectations about 0.41 and confusion about how we do our version numbering right now.
Yup. Regarding packaging cycles, I think the process we've adopted has worked pretty well. We have very frequent (nightly) releases for people who want to really stay on the bleeding edge, but we make no promises that there's any Q.A or even that it'll necessarily work, so it's low commitment from a packaging point of view. And we have infrequent but highly Q.A.'d versions that people can use that are not keen on running unstable code and for whom an upgrade every few months fits well with their schedule, especially given how much new goodness each release has had.
So I like that for our "stable" series we use regular version numbers (0.38, 0.38.1, 0.39, etc.) and for our "devel" series we use build-dates. Makes it extremely clear that one is expected to be stable and one might not be.
I've also noticed that we've had few problems with communicating with users about what version they're using when reporting bugs, so this system seems to be working pretty well. The one change I'd suggest is for the devel versions to cause the build-date to be indicated in the about screen. That way if someone's running a nightly from 3 weeks ago, they won't get confused into thinking that they're running the stable 0.40 version.
I've often thought about if we should be porting bug fixes to the stable branch and create 0.40.1, 0.40.2, etc. Specifically what I'm watching for is someone to voice an interest in being the "stable series maintainer" and take on the role. Currently we have not heard strong interest in doing this from either developers or users, so my guess is that the time is still not quite right to take this approach. One of the main needs for this approach is for security issues, but since Inkscape is not really the type app that opens security holes there doesn't seem to be as much need.
Bryce