Re: [XForms] Version numbers and next release - please read!

[LukenShiro]

Il giorno Sun, 12 Dec 2010 03:17:37 +0100
Jens Thoms Toerring <address@hidden> ha scritto:
>    So I consider naming the next version I originally intended
> to be 1.0.94 to instead 1.1. And from then on we would bump up
> the revision number for all changes that aren't just bug fixes.
> Now I don't know if that would inconvenience anyone of you and
> thus I would like to get some feedback on the whole thing. So
> please don't hold back and tell me about all possible problems
> you may envision to result from that!

GNU guidelines pointed out by saulgoode sound convincing to me to some
extent.

I suppose all depends on how many modification (except bugfixes, of
course) will predictably take place and how frequent are the stable
releases planned for the future.
For bugfix only (without incompatible changes) I'd use the 3rd number
(fixlevel or whatever): b in x.y.b
For new implemented functions (without incompatible changes) I'd use y
in x.y.b
(or two numbers if planned modifications and stable releases are not
few, before going to a new major version: e.g. 1.01.0 ... 1.09.0 ...
1.10.0 ...)
I'd use bugfix number also for pre-releases to be tested: 1.2.1
(old stable with 1st series of bugfixes) .. 1.2.91 (1st pre- of
1.3.0) .. 1.2.92 (2nd pre- of 1.3.0) ..etc.. 1.3.0 (new stable version)

Nonetheless I would not use odd minor version (yy in x.yy.b) as
temporary development branch. See later.

>    Another thing I would like to get done before going down
> that road (if we decide to do that) is to fix bugs. Christmas
> holidays are around the corner, so I might have some extra
> time for working a bit more on XForms again than in the last
> months. So also report everything you consider to be bugs to
> help get them fixed now.

OK ;)
 
> Beside that I would like to have some kind of "development
> branch" were we can play around with new ideas and that you
> can test if you like to. I have no good ideas yet for a con-
> sistent naming scheme for that, so I will be grateful for all
> input.

If new ideas are (as I guess) potentially backwards incompatible, as
major version (x in x.y.z) bump is normally used when a major rewrite
takes place or there is a great number of structural changes (AFAIK), a
version 2.0.0 might be confusing to be used now as "playground". I'd use
a version number who cannot be misunderstood for being stable such as
1.9.<iso-format-date> (e.g. 1.9.20101212) as development/unstable
"release".
You may then want to backport to e.g. 1.x.91 (pre-release of next stable
version) from devel- some ideas who are not breaking external API (at
least arguments and return values) and that are deemed to be
"stabilized" and useful for general public.

Just my 2c :)

-- 
GNU/Linux * Slackware64 current
LU #210970 SU #12583 LM #98222/#412913