You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2005/12/15 09:34:22 UTC

1.0 release Candidate 2...some guidelines

All,

Optimism got the better of us and our first attempt at a release met with some 
well deserved -1's for reasons that are not anyone's fault.  however, it has 
pointed out some obvious flaws in our process that I'd like to address now.

First, we have a Press release that reached the public a little too soon.  Not 
withstanding that issue I do not want to put out a rushed release to satisfy the 
press release.  The web site is updated and we need to get the binary out as 
soon as possible and I hope the second spin of the release will correct that 
problem.

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?

Finally, It looks like the file corruption issue pointed out regarding the 
source tar balls was some confusion over how files that are 100 characters long 
were handled on Solaris.  It sounds like a Solaris bug and not ours.

We've made really good progress in squashing the bugs and getting features in so 
  let's take this final few days and finish the release with gusto.  We're 
almost there.



Re: 1.0 release Candidate 2...some guidelines

Posted by Dain Sundstrom <da...@iq80.com>.
+1

-dain

On Dec 15, 2005, at 10:00 AM, Alan D. Cabrera wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I second that.  So long as we do not make an actual tag w/ that date,
> i.e. have a time series of release candidates in the tags directory.
>
>
> Regards,
> Alan
>
>
> Matt Hogstrom wrote, On 12/15/2005 9:12 AM:
>> Good idea Paul...I like the date time string idea.
>>
>> Paul McMahan wrote:
>>
>>> On 12/15/05, Matt Hogstrom <ma...@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
>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD4DBQFDoa9O1xC6qnMLUpYRAvh0AJdhPFx2Iqw4Xq4a6EIL9dpTOzDFAJ0T6j9N
> ClFIsY+jLB6racfd8nZltA==
> =NZnc
> -----END PGP SIGNATURE-----


Re: 1.0 release Candidate 2...some guidelines

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I second that.  So long as we do not make an actual tag w/ that date,
i.e. have a time series of release candidates in the tags directory.


Regards,
Alan


Matt Hogstrom wrote, On 12/15/2005 9:12 AM:
> Good idea Paul...I like the date time string idea.
> 
> Paul McMahan wrote:
> 
>> On 12/15/05, Matt Hogstrom <ma...@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
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFDoa9O1xC6qnMLUpYRAvh0AJdhPFx2Iqw4Xq4a6EIL9dpTOzDFAJ0T6j9N
ClFIsY+jLB6racfd8nZltA==
=NZnc
-----END PGP SIGNATURE-----


Re: 1.0 release Candidate 2...some guidelines

Posted by David Blevins <da...@visi.com>.
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 <ma...@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
>


Re: 1.0 release Candidate 2...some guidelines

Posted by Matt Hogstrom <ma...@hogstrom.org>.
Good idea Paul...I like the date time string idea.

Paul McMahan wrote:
> On 12/15/05, Matt Hogstrom <ma...@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
> 


Re: 1.0 release Candidate 2...some guidelines

Posted by Paul McMahan <pa...@gmail.com>.
On 12/15/05, Matt Hogstrom <ma...@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