On Mon, Nov 22, 2010 at 6:44 PM, Nate Coraor <nate@bx.psu.edu> wrote:
I'd also welcome official version numbers for Galaxy. It would also make it easier for citation purposes (e.g. Galaxy workflow available in online supplementary materials, tested with Galaxy version x,y,z).
These already exist as the numerical and unique changeset IDs, they just don't take the traditional X.Y.Z form.
Quite - and they are much less useful as a result. Hg changeset IDs (and likewise git hashes) are numerical (if you understand hex) and unique, but one important drawback is they are not strictly increasing. You can't take two changeset IDs and know which is older and which is newer. Changeset IDs are also not PEP 386 compliant version numbers ;) http://www.python.org/dev/peps/pep-0386/ In a method section of a paper I really don't want to write "We used Galaxy changeset 8729d2e29b02", I'd rather say "We used the Galaxy distribution release of 17 Nov 2010" (that date may be wrong, bitbucket says "5 days ago" rather than a real date), but it would be nicer and more normal to just say "We used Galaxy release 1.2.3" (or whatever). I also very much agree with the point Kostas made about writing tools and wanting to say "This works on Galaxy version 1.2.3 or later". Here again I'd opt for the date as a human friendly substitute since the changeset ID is quite inappropriate in my opinion. Yes, I recognise this is a partly a social rather than technical issue, and isn't going to stop me using or recommending Galaxy, but I think this needs to be voiced. For people using the Penn State Galaxy instance this is largely irrelevant, but for local Galaxy installs (and there may be more than one per institute) having an easy way to check their version number would be very useful (I think it should be included in the footer of the welcome page or something by default). Even for simple things like cross checking bugs, a simple Galaxy version number would be useful. Finally, If you hope to get Galaxy provided as a package by Linux distributions on day (which might be a nice idea if development ever slows down), then they also prefer "tradition" version schemes. I've probably gone on enough now ;) What do other people think?
I'd also like to ask a technical question about the galaxy-dist and galaxy-central repositories: Is the default branch on galaxy-dist identical to (but of course usually older than) the default branch on galaxy-central?
Correct.
Thank you.
[I'm thinking about the occasional need to update a production server originally cloned from galaxy-dist to get a fix from galaxy-central before you guys make it available on galaxy-dist]
This should always be fine from a Mercurial point of view.
Great. Thanks for the clarification wrt the branch situation. Peter