John Ralls <jra...@ceridwen.us> writes:
>> 2. Versioning.
>>
>> We currently use a version scheme gigantic.major.minor[-build]. Like 2.6.19
>> (and an optional -2 if we had to release more than once to get it right).
>> For
>> the 3 levels we really only use two. The 2 in front has been updated when
>> gnucash migrated from gtk to gtk2. We will migrate to gtk3 for gnucash 2.8
>> yet we don't changed to 3.0 as a result. The migration to gtk2 has
>> been a long
>> time ago and the software world has evolved since then. Release cycles in
>> general have shortened. Incremental changes are usually preferred over big
>> bang changes. So I think our numbering scheme is in for a modernization.
>>
>> Here's my proposal:
>> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
>> build] instead.
>> Major releases would increment the first number. Bugfix releases the second.
>>
>> So after 2.8 the next major release would be 3.0, bugfix releases for that
>> major release would become 3.1, 3.2, 3.4...
>>
>> I would drop the idea of odd numbers being development snapshots and even
>> numbers being stable ones. Instead I see several options, I haven't decided
>> which one is most elegant/kludgy:
>>
>> Option A: let's number development snapshots starting from
>> x.90. That gives us
>> 10 development snapshots. If that's not enough we can either choose
>> to start a
>> bit earlier, like x.80 or from x.98 jump to x.980 to give us 20 more.
>> Option B: as a variation all development snapshots do use a 3 number
>> version:
>> x.99.z with 99 clearly indicating "right before the next major release" and
>> z
>> incrementing with each snapshot.
>>
>> This makes development snapshots slightly more verbose in their numbering
>> but
>> gives us cleanly incrementing stable releases. The latter are more visible
>> to
>> most users, so I personally care more about those.
>>
>> The development snapshots between 2.8 and 3.0 fall a bit in between. We
>> could
>> choose to handle them old style or new style as we see fit. Old style would
>> mean we'd still work with a 2.9.x series. New style would mean we'd
>> start with
>> 2.8.90/2.8.99.1 as we see fit.
>>
>> Thoughts ?
>
> I’m indifferent to the versioning system as long as it’s consistent,
> but the distro packagers aren’t. Some of them recite the “Semantic
> Versioning” [1] mantra even though it really applies only to
> libraries.
>
> Back when we released 2.6 we were unsure about whether the coming
> version would be 2.8 or 3.0. One of the criteria proposed was that we
> should call it 3.0 if we upgraded to Gtk+3. Well, we have, so maybe
> the coming release should be 3.0.0 instead of 2.8.0. That would
> certainly be consistent with the Gnome guidelines [2] that include a
> major change in the GUI as a reason for bumping the major version.
>
> Should some of the component libraries (especially libgnucash) have
> separate versioning that follows the semantic versioning rules?
I see no reason that we can't jump from 2.7.x to 3.0[.0] when we release.
And since we DID upgrade to GTK3, I think we should do that.
As for whether to drop the third entry is less important to me, but I
still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
leave 3.1/3.2 for more major changes.
I'm fine with dropping the even/odd and just jumping t0 3.0.80 (or 90)
for testing pre-releases.
> Regards,
> John Ralls
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
