The "standard" gem versioning scheme doesn't work well with the flow of Haml development. Every non-patch release of Haml includes plenty of features and a few backwards-incompatibilities. The development versions change dramatically over time, as development versions are wont to do. Moreover, other projects (Compass prior to Sass 2.2, and currently a theme generator of Dr. Nic's, I believe) need to be able to specify dependencies on development versions. This is why we provide the haml-edge gem. But this gem wouldn't be very useful if it didn't have fine-grained versioning, which is only possible if we reserve odd-numbered releases for the development version. I don't understand why this odd/even scheme doesn't work well with gem numbering, at least in any technical sense.
The question Rhett raised as to the distinction between the major and minor versions is a valid one. Historically, we bumped the major version number when it felt right to do so - after major language changes or something like that. However, the pace of releases has slowed some since then, in part because every release tends to have reasonably major language changes (e.g. control structures in Sass 2.2, new syntax in Sass 2.4). However, it's not clear to me what a better distinction between major/minor version numbers would be. Haml/Sass development has two tracks: the stable track, which is mostly bugfixes, and the unstable track, which is new features and backwards-incompatibilities. I don't feel any need to separate this further into three development tracks (one for major, one for minor, one for patch). Before I make any change to the semantics of the version numbers, I'd need to have a good idea of what the new semantics would be and why that would be an improvement. One thing I am sure of: the versioning system is not going to change until after 2.4 is released. We have infrastructure in place for dealing with the stable releases under the current system that I don't want to disrupt, and 2.4 has been the version number we've been telling people to expect for quite a while now, so I'm not going to change that out from under them. - Nathan On Wed, Nov 25, 2009 at 8:49 AM, Andrew Shebanow <[email protected]>wrote: > I agree with Wincent that avoiding '>' dependencies is a good strategy > for app developers. But I also have to note that the linux style odd/ > even version numbering scheme is not a good match with the gem version > numbering scheme we all have to live with for better or worse. > > It would be great if you could move to a style more in line with other > gem-based distributions: use version numbers for stable releases, and > use "-pre" (or similar) suffices when releasing experimental stuff out > of trunk. The latter is actually rarely necessary, btw: most people > who want the latest bits are comfortable getting and building their > gems directly from a git clone. > > -- > > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
