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.
-mental