It seems to me it might make sense to drop the idea of having releases with conventional version numbers (eg 1.0, 1.1) and simply use the svn version numbers for everything (releases as well as svn checkouts). Then we would have periodic releases which would be listed on the downloads page (along with their dates). The advantages are - only one series of version numbers for svn copies (which is what is mostly used) and releases - only one set of checks for versions are needed to use both the svn copy and the releases (eg if you want to change how your program works before and after some functionality changes) - the version numbers are maintained automatically and are very meaningful (eg if the versions are the same, then the code is the same) - different modules have different versions is quite natural - people creating modules don't have to think about versioning (assuming they use svn) - given a version number, there is one, uniform, way of getting it
Disadvantages: - the version numbers don't exactly roll off the tongue (eg the kernel is 8016) - it isn't obvious what version of a module goes with what version of another module (but this isn't obvious in general, only for modules that are released as part of IMP and when a release version is used).
Thoughts?
On 1/6/11 2:45 PM, Daniel Russel wrote: > It seems to me it might make sense to drop the idea of having > releases with conventional version numbers (eg 1.0, 1.1) and simply > use the svn version numbers for everything (releases as well as svn > checkouts).
That doesn't make a lot of sense since SVN revisions increase strictly chronologically and so would be essentially meaningless with branches. This precludes, for example, a 1.0.1 bugfix release for users that don't want to break everything by upgrading to 1.1 or 2.0. Release numbers are, after all, a helpful shorthand precisely so users don't have to memorize revision numbers (which are are also tied to the revision control system, of course, so would go out the window if we switched to git or Mercurial). Some of these other systems have even less memorable revision "numbers" - a typical git revision "number" is "7950659dc9ef7f2b50b18010622299c508bfdfc3", for example.
Ben
participants (2)
-
Ben Webb
-
Daniel Russel