On Thu, Dec 02, 2004 at 06:12:55PM -0500, MenTaLguY wrote:
Treating version numbers like decimal numbers is a bad idea because you invariably run out of room, and engender unrealistic expectations about how close a specific future version is. I've been through that on some other projects and it's not pretty.
This is one of my major complaints about Perl. They treat their versions (internally) as decimal, and there's a lot of hidden magic that unexpectedly blows things up. Like going from 1.49 to 1.5, etc.
Yes, if we keep the major.minor.point format, some people are going to think that e.g. 1.5 comes after 1.42. Maybe we should start including the implicit point release (.0) on our minor release numbers as other projects do.
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.