Re: Time to cut an Olio release

[Craig L Russell <Cr...@Sun.COM>]

Replying a bit late here, but...

As long as the community agrees, the project can make the policy that  
there is no guarantee of any compatibility with major release 0.

Once there's a release 1, compatibility rules apply.

Craig

On Feb 20, 2009, at 10:31 AM, Shanti Subramanyam - PAE wrote:

> This sounds good to me. But we still need to determine when we  
> advance the minor number (I'm going to assume we will stick with a  
> major number of 0 for now).
> I am not sure if the default understanding of "backward  
> compatibility will be maintained for minor updates" will work for us  
> (and in fact it doesn't work for other projects - hadoop 0.19.0 is  
> incompatible with 0.18.x)
>
> Shanti
>
> On 02/19/09 21:17, Akara Sucharitakul wrote:
>> I'm chiming in late here. There are pros and cons with both. The  
>> major.minor is good, but has to be advanced manually. You cannot  
>> automatically build it into the build/packaging process. The date  
>> can be automatically generated. In order to take advantage of both,  
>> I suggest having both mechanisms:
>> 1. Use major minor as version number. I don't really care whether  
>> is major.minor or major.minor.dot, but prefer not to have the dot  
>> for less complexity.
>> 2. Provide build date as part of the package. So instead of having  
>> something like snv_102 we'll have Olio 0.1 b021909 or Olio 0.1.1 b  
>> 021909.
>> When we have a solid build, we'll just promote it to the official  
>> 0.1 and tag the repository with the build number. At least this is  
>> the way I do it in Faban and allows me to easily track issues when  
>> they are reported, even on non-final builds.
>> -Akara
>> Craig L Russell wrote:
>>> The way everyone describes the major.minor.update releases in this  
>>> thread seem to be consistent.
>>>
>>> I have no vote, but if no one objects, go for it.
>>>
>>> Craig
>>>
>>> On Feb 18, 2009, at 3:45 PM, Damien Cooke wrote:
>>>
>>>> Shanti,
>>>> This mechanism  for labeling releases is extremely simple and  
>>>> widely used.  It provides people with an insight to the magnitude  
>>>> of the change.  But what needs to be determined is what  
>>>> constitutes a x.x.X update and what constitutes an x.X.x update.   
>>>> In the past I have used X.x.x update for interface changes x.X.x  
>>>> update for functional enhancement and x.x.X for minor fixes.
>>>>
>>>> Regards
>>>> Damien
>>>>
>>>> On 18/02/09 11:25 AM, Shanti Subramanyam wrote:
>>>>> Here are some guidelines for versioning : http://incubator.apache.org/guides/releasemanagement.html#best-practice-versioning
>>>>>
>>>>> I know Akara likes to use dates for release names and the  
>>>>> guidelines above certainly don't preclude it. I checked the  
>>>>> existing incubator projects and they're all using the / 
>>>>> major.minor.point/ system of versioning.
>>>>> If we follow this convention, our first release will be 0.1.0.  
>>>>> The advantage to this is that if we make only minor changes and/ 
>>>>> or fix bugs we can simply update the point (to 0.1.1). This  
>>>>> naming gives the user some idea of the level of changes that  
>>>>> went in.
>>>>>
>>>>> Does anyone else have a suggestion or opinion on the above ?
>>>>>
>>>>> Shanti
>>>>>
>>>>> William Sobel wrote:
>>>>>> A month sounds like it's doable, or should be! I think we  
>>>>>> already have a planned release structure in the repo. Now for  
>>>>>> the toughest question, how do we want to number the releases?
>>>>>>
>>>>>> Cheers,
>>>>>> - Will Sobel
>>>>>>
>>>>
>>>> -- 
>>>> <email_banner.gif> <http://www.sun.com/eco>     *Damien Cooke*
>>>> Open Scalable Solutions Performance
>>>> Performance & Applications Engineering
>>>>
>>>> *Sun Microsystems *
>>>> Level 2, East Wing 50 Grenfell Street, Adelaide
>>>> SA 5000 Australia
>>>> Phone x58315 (x7058315 US callers)
>>>> Email Damien.Cooke@Sun.Com
>>>>
>>>
>>> Craig L Russell
>>>
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!