Re: Conventions for release numbering

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
>>> the
>>> 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@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq