yeah, i suck. this was of course supposed to go to the list.
----- Forwarded message from "Brian J. Tarricone" <bjt23@...> -----
Date: Tue, 31 Aug 2004 12:23:51 -0700
From: "Brian J. Tarricone" <bjt23@...>
To: Sean Egan <seanegan@...>
Subject: Re: [Gaim-devel] Version numbers
On 08/31/04 12:36, Sean Egan wrote:
> On Tue, 31 Aug 2004 09:02:30 -0700, Christian Hammond
> <chipx86@...> wrote:
> >Sean states in his e-mail that "most people acknowledge
> > that there is no real difference between 0.84 and 84, and most people
> > agree that given our current style of development, 84 seems more
> > appropriate." I've been seeing more people disagree with the vXX
> > scheme than agree with it, so I'm not sure where that comes from, but
> > let's not make a decision right away. Nobody says we have to make this
> > change now.
>
> I haven't seen a single person say "let's keep our current versioning
> scheme, and have every release forever be zero dot whatever. Everyone
> agrees that doing that would be effectively the same, but better than
> dropping the zero dot. Plenty of people have expressed interest in
> switching to a more meaningful scheme than either of those, but even
> those seem to admit that 84 is the same, but better, than 0.84. I
> guess I probably just misunderstood everyone.
then here's my vote. i think the current scheme is fine.
on the other hand, i might as well try to summarise what i've seen so far
lurking in this thread. these are the pros and cons as i see them, without
regard to whether or not anyone thinks these issues are important - that's for
the devs to ultimately decide. hopefully this list will be useful to that end.
* keep current 0.XX scheme
-PROS: it's how it's been done for a while now (since 0.43ish?), and i think
people are used to it. it's simple, effective, and accurately represents
gaim's simple release policy of not maintaining separate branches, and keeping
to a sequential time-based release schedule where successive releases are
generally a combination of bug fixes and feature enhancements. if somewhere
down the road, gaim eventually decides to go 1.0, this is doable without
messing up any package managers with regard to their version ordering.
-CONS: it's not terribly descriptive in that "this is the XXth release of
gaim" is not a really useful piece of information (aside from nostalgia). it's
constantly a 0.xx release, which many people (possibly erroneously) believe
indicates alpha, or "not ready for prime time", which may cause some users
to shy away from using gaim.
* drop the "0." and use vXX
- PROS: reluctant users that think "0." denotes alpha will feel better about
using gaim. like the current scheme, it's simple, effective, and accurately
represents (blah blah blah see above).
- CONS: if gaim eventually wants to change release numbering again to something
more "traditional", it will be hard to do without starting off with the major
number as something very high, at least without making headaches for package
managers that use x.y.z version numbers to decide what constitutes a "newer"
release. also, this type of scheme is unusual, and might be a little confusing
to new users (especially if someday gaim ends up being version 93.2.6).
* drop the current scheme and go to a "traditional" x.y.z scheme
- PROS: since this is regarded as "normal", users will see the version number
and have a pretty good idea as to what it means. even keeping the 0.XX scheme
can make use of this, as 0.82.1 did, to denote a quick "oops, we f-ed up"
release. this also leads the way to patching older gaim releases if such a
thing is desired for whatever reason. there are also benefits here when
libgaim is finished (see my rationale below).
- CONS: none that i can think of, aside from losing the ability to count the
number of total gaim releases by looking at the version number, and perhaps
not really reflecting gaim's overall release strategy (or lack thereof) in
the version number.
so that's kinda how i see it, and now i'll weigh in with my opinion.
first, i'd like to recommend a traditional x.y.z scheme. once libgaim is
separated out of gaim, i'm betting the most efficient way to get feature
improvements out is by releasing libgaim and gaim (as in, the gtk2 frontend)
separately. libgaim, as a library, should use a standard versioning scheme
for two reasons: 1) it's what people expect in a library, 2) it has been
proven by example to be a workable scheme. the library is going to have an
API, and, after that's stabilised, the API should have a version number
(usually the library's major number). incompatible changes to the API should
increase the major number. backward compatible additions to the API should
increase the minor number, and succesive bugfix/performance releases should
increase the micro. this is a common practice, and i see little reason to
fly in the face of tradition here. doing it "just to be different" is
childish and pointless (not saying anyone holds his viewpoint, i'm just
pointing this out).
as for gaim the gtk2 frontend, an arbitrary release will obviously depend on
a specific major version of libgaim, and optionally a minimum minor version
if necessary. so i suppose it's somewhat arbitrary as to how the frontend
does its versioning. but, for clarity and lack of confusion, it would be
nice if gaim's x.y matched with the minimum libgaim x.y that it requires.
that's about it. thanks for reading, if you made it this far - i know this
thread has been going on for quite a while, and i'm sorry to add to it.
-brian
----- End forwarded message -----
|
