How about postgresql-M.c.i ? :)
M == Meaningless/Marketing: meaningless number incremented for marketing
purposes when we want people to think a great deal has changed
c == Compatibility: we might break your binary compatibility with older
installed databases when this changes (dump/restore recommended)
i == Increment: We change this whenever we release something new, but we
don't break compatibility (dump/restore not required)
That's pretty good, two of the three digits are technically significant.
For PostGIS, only the last digit is significant (compatible increments).
The first two we alter more or less on a whim.
Marc G. Fournier wrote:
> On Sun, 12 Jun 2005, elein wrote:
>> On Sun, Jun 12, 2005 at 11:13:15PM -0300, Marc G. Fournier wrote:
>>> On Sun, 12 Jun 2005, elein wrote:
>>>> (No, wait, I'm not starting a release numbering discussion.)
>>>> If we have release 8.0.3 where 8 is the Major releae,
>>>> 0 is the minor release and 3 is the version (revision?),
>>>> how would we refer to a generic release number:
>>>> postgresql-M.m.v ? postgresql-M.m.r ?
>>>> Is this our convention? Do either of these work?
>>> Assuming v==version and r==release, is there a big difference between
>>> two? How are each defined?
>> That is my question! What do we conventionally use?
> Neither and both? Since I don't know the difference (if any) between
> the final being considered r(elease) or v(ersion) ...
> Its always just been 'Major'.'Minor'.'Bug Fixes' ... so is 'Bug Fixes'
> == version or release?
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
In response to
pgsql-advocacy by date
|Next:||From: Chris Browne||Date: 2005-06-13 15:24:08|
|Subject: Re: Linux Journal 2005 awards|
|Previous:||From: Robert Treat||Date: 2005-06-13 14:41:53|
|Subject: Re: Conventions for release numbering|