On Feb 12, 2009, at 5:40 PM, Magnus Holm wrote:
However, let's focus on the future! First of all, we need some plan
on how we should name the releases.
Basic. http://www.rubygems.org/read/chapter/7
Knowing how much changed on 2.0 I expect that some things are very
different and analogous to API change, so 2.0 be it. 1.5.180 is just
"tiny" 180
and a bugfix release, besides people who installed it from _why's
server will not get screwed when it pops up on their server and they
set it up as a dep.
What about keeping the rev-number in the version number and make it
some sort of "patchlevel"?
What worked well for me is upping the "tiny" revision every time I say
"this is a tagged release, and it goes out to rubyforge". Putting int
SHAs in
there doesn't really scale because less has to still mean "older" and
more has to mean "younger".
So 2.0 becomes 2.0.308, and any bugfixes which doesn't change the
"external" API can we release as 2.0.xxx. Should make it simpler to
release plain bugfixes without bumping the version number too high.
2.1 would then contain some more new stuff. Should also blend nicely
into pre-releases since they can keep the same structure.
Why not just 2.0.0 with a tag, then 2.0.1 with a tag and so on? Then
you also know everytime you release something you have a tag for it.
And things like rebases will not ruin your schemes
--
Julik Tarkhanov
[email protected]
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
