geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: 1.0 release Candidate 2...some guidelines
Date Thu, 15 Dec 2005 23:17:52 GMT
I'm not a big fan of having archives where the zip or tar name  
doesn't match the inside of the archive or the version number (i.e.  
foo-1.0-123456.zip --> foo-1.0/).  All our proposed binaries would  
extract to the exact same directory.  If someone forgets to delete  
the old foo-1.0 directory before unpacking the newest proposed  
binary, who knows what kind of strange errors they will report.

It might be a good idea, I'm just a little too burnt out to be  
excited about adding another step to our release process (i.e.  
renaming the files produced by maven then renaming them back when we  
make them official).

-David

On Dec 15, 2005, at 9:12 AM, Matt Hogstrom wrote:

> Good idea Paul...I like the date time string idea.
>
> Paul McMahan wrote:
>> On 12/15/05, Matt Hogstrom <matt@hogstrom.org> wrote:
>>>
>>> Second, someone pointed out (I think it was Jacek) that we did  
>>> not include
>>> a
>>> notation in the binary about what the release candidate was so  
>>> that it is
>>> not
>>> confused with the final release.  Before releasing another cut I  
>>> would
>>> like the
>>> naming convention of the binary and the directories to be clearer  
>>> as to
>>> what
>>> they contain otherwise this will get confusing.  My suggestion is  
>>> that the
>>> name be:
>>>
>>> geronimo-jetty-1.0-rc[n].tar.gz for example.  Where [n] is the  
>>> number of
>>> the
>>> release candidate (and we are now on number 2).  The next set of  
>>> images
>>> should
>>> follow this convention to ensure we are not confusing the users.   
>>> I know
>>> these
>>> are release candidates and this isn't required but it would make  
>>> me sleep
>>> better
>>> at night :)  The directory that is actually contained in the zip  
>>> will
>>> still be
>>> geronimo-1.0.  Thoughts?
>> Matt,  including a notation in the filename seems like a good idea  
>> and could
>> help prevent confusion.  I've also seen projects use a date string  
>> instead
>> of a release candidate number for this purpose.  Using a date  
>> string is
>> helpful since it makes it obvious when the image was created plus  
>> avoids
>> publicizing how many unsuccessful attempts there have been (not  
>> saying that
>> would be an issue in this case :o)
>> Best wishes,
>> Paul
>


Mime
View raw message