release preparation: release guide

[Xavier Hanin <xa...@gmail.com>]

Hi,

To prepare the release, I've created a developer documentation page
including a release guide. It's already in svn, and will be available on the
web site in about one hour:
http://incubator.apache.org/ivy/doc/dev.html

I would like to get some feedback on this doc, to see if it makes sense or
not (from an Apache but also build and release point of view). One thing I
still don't know how to address is the case of a vote rejecting the release.
In this case, we'll need to update something and submit again the release.
So, is tagging before the vote a good idea, or should we tag only when the
vote is accepted (note that the release is already build from a branch, so
it's already safely reproducible)?

Another thing with which I'm not familiar is signing. Do signing files alter
them? I ask this question because we need to provide checksums for the
artifacts, so I'd like to add checksum calculation to the release script,
but since signing occur after the release script, if it alters the artifacts
the checksums must be calculated after signing.

Any idea and feedback is welcome, I think we are not too far from being able
to release 2.0.0-alpha1!

- Xavier

Re: release preparation: release guide

[Xavier Hanin <xa...@gmail.com>]

On 4/1/07, Stefan Bodewig <bo...@apache.org> wrote:
>
> On Fri, 30 Mar 2007, Xavier Hanin <xa...@gmail.com> wrote:
>
> > Ok, so I'll add checksum generation in the build-release.xml
> > script. But maybe signing could also be part of the script? If so,
> > any example I could use?
>
> I have simple shell script that I've taken from Antoine at once.
>
> ,----[ signdist ]
> | #!/bin/sh
> | for i in `find distribution \( -name \*.bz2 -o -name  \*.zip -o -name
> \*.gz \)`
> | do
> |      echo "Signing " $i
> |      gpg -a -b --force-v3-sigs $i
> | done
> `----
>
> which isn't really too fancy - but I don't need to remember which
> arguments gpg needs to create PGP 5.x compatible signatures that way.


Thanks. Is it a good idea to include this script in Ivy build script, or
adding to the release guide is enough?

I think Antoine has added a sign task to commons-openpgp (in Jakarta
> Commons' Sandbox) but I've never used it myself.


For first release at least I think using unix tool will be good (and simple)
enough.

> Oh, and one last question about distribution format: Ivy releases
> > used to be distributed only in zip, should we also provide tar.gz?
>
> Yes, please, this might be nice for people living on Unix systems
> without InfoZIP (not that they are too common these days).


Ok, so I'll update the build-release.xml script.

Thanks for your help,

- Xavier

Stefan
>



-- 
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: release preparation: release guide

[Stefan Bodewig <bo...@apache.org>]

On Fri, 30 Mar 2007, Xavier Hanin <xa...@gmail.com> wrote:

> Ok, so I'll add checksum generation in the build-release.xml
> script. But maybe signing could also be part of the script? If so,
> any example I could use?

I have simple shell script that I've taken from Antoine at once.

,----[ signdist ]
| #!/bin/sh
| for i in `find distribution \( -name \*.bz2 -o -name  \*.zip -o -name \*.gz \)`
| do
|      echo "Signing " $i
|      gpg -a -b --force-v3-sigs $i
| done
`----

which isn't really too fancy - but I don't need to remember which
arguments gpg needs to create PGP 5.x compatible signatures that way.

I think Antoine has added a sign task to commons-openpgp (in Jakarta
Commons' Sandbox) but I've never used it myself.

> Oh, and one last question about distribution format: Ivy releases
> used to be distributed only in zip, should we also provide tar.gz?

Yes, please, this might be nice for people living on Unix systems
without InfoZIP (not that they are too common these days).

Stefan

Re: release preparation: release guide

[Xavier Hanin <xa...@gmail.com>]

On 3/30/07, Stefan Bodewig <bo...@apache.org> wrote:
>
> On Thu, 29 Mar 2007, Xavier Hanin <xa...@gmail.com> wrote:
>
> > http://incubator.apache.org/ivy/doc/dev.html
> >
> > I would like to get some feedback on this doc, to see if it makes
> > sense or not (from an Apache but also build and release point of
> > view).
>
> * be more specific about the version of JUnit (3.x or 4.x) in the
>   building section - unless it doesn't matter, of course.


I haven't tested with junit 4.x, so I'll  update the doc to ask for a
3.8.2version

* creating a branch is optional, it depends on the project's
>   preferences, I guess.  We haven't created a branch for 1.7.x, yet,
>   for example.  Maintaining two branches can be painful, so it may be
>   a good idea to defer branching until you make changes to your trunk
>   that you don't want to see in your next 2.0.x release.


The branch in my doc is only a release branch, not a branch for development.
It allows to prepare the release in isolation, and commit things done only
for the release (like updating template files). The aim is to avoid
committing anything on that branch after the release is complete. If we tag
only after the vote is successful, we could even remove the branch as soon
as we tag the release. Does it make sense?

* I'd add announce@apache.org to the "Announce" section.


I'll do.

> One thing I still don't know how to address is the case of a vote
> > rejecting the release.  In this case, we'll need to update something
> > and submit again the release.  So, is tagging before the vote a good
> > idea, or should we tag only when the vote is accepted (note that the
> > release is already build from a branch, so it's already safely
> > reproducible)?
>
> When I released AntUnit and the .NET Antlibs I created the tags in my
> filesystem (simple svn cp on directories instead of URLs) and
> committed them after the vote had passed.  This is mostly a matter of
> taste since in svn a tag is not really frozen.  I.e. if the vote fails
> you can simply either modify the tag or delete and recreate it.


So I think I'll say to tag only after the vote, since release preparation is
already done on a branch, there is no risk for concurrent modifications.

> Another thing with which I'm not familiar is signing. Do signing
> > files alter them?
>
> No.  You'd create a detached signature which just like the checksum
> files is stand-alone.


Ok, so I'll add checksum generation in the build-release.xml script. But
maybe signing could also be part of the script? If so, any example I could
use?

Oh, and one last question about distribution format: Ivy releases used to be
distributed only in zip, should we also provide tar.gz?

- Xavier

Stefan
>



-- 
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: release preparation: release guide

[Stefan Bodewig <bo...@apache.org>]

On Thu, 29 Mar 2007, Xavier Hanin <xa...@gmail.com> wrote:

> http://incubator.apache.org/ivy/doc/dev.html
>
> I would like to get some feedback on this doc, to see if it makes
> sense or not (from an Apache but also build and release point of
> view).

* be more specific about the version of JUnit (3.x or 4.x) in the
  building section - unless it doesn't matter, of course.

* creating a branch is optional, it depends on the project's
  preferences, I guess.  We haven't created a branch for 1.7.x, yet,
  for example.  Maintaining two branches can be painful, so it may be
  a good idea to defer branching until you make changes to your trunk
  that you don't want to see in your next 2.0.x release.

* I'd add announce@apache.org to the "Announce" section.

> One thing I still don't know how to address is the case of a vote
> rejecting the release.  In this case, we'll need to update something
> and submit again the release.  So, is tagging before the vote a good
> idea, or should we tag only when the vote is accepted (note that the
> release is already build from a branch, so it's already safely
> reproducible)?

When I released AntUnit and the .NET Antlibs I created the tags in my
filesystem (simple svn cp on directories instead of URLs) and
committed them after the vote had passed.  This is mostly a matter of
taste since in svn a tag is not really frozen.  I.e. if the vote fails
you can simply either modify the tag or delete and recreate it.

> Another thing with which I'm not familiar is signing. Do signing
> files alter them?

No.  You'd create a detached signature which just like the checksum
files is stand-alone.

Stefan

Re: release preparation: release guide

[Xavier Hanin <xa...@gmail.com>]

On 3/31/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> I saw that the example in src/examples/go-ivy/build.xml also mention
> the version (and still jayasoft).


Yes, but we have a circular problem here: go-ivy need a version available on
the net to run, so we can't update it to the released version before the
release is published... OTOH, releasing without updating to the new version
is not a very good thing. We have the same problem for Ivy build itself. So,
if anyone has an idea, I take it!

- Xavier

Gilles
>
> 2007/3/29, Xavier Hanin <xa...@gmail.com>:
> > Hi,
> >
> > To prepare the release, I've created a developer documentation page
> > including a release guide. It's already in svn, and will be available on
> the
> > web site in about one hour:
> > http://incubator.apache.org/ivy/doc/dev.html
> >
> > I would like to get some feedback on this doc, to see if it makes sense
> or
> > not (from an Apache but also build and release point of view). One thing
> I
> > still don't know how to address is the case of a vote rejecting the
> release.
> > In this case, we'll need to update something and submit again the
> release.
> > So, is tagging before the vote a good idea, or should we tag only when
> the
> > vote is accepted (note that the release is already build from a branch,
> so
> > it's already safely reproducible)?
> >
> > Another thing with which I'm not familiar is signing. Do signing files
> alter
> > them? I ask this question because we need to provide checksums for the
> > artifacts, so I'd like to add checksum calculation to the release
> script,
> > but since signing occur after the release script, if it alters the
> artifacts
> > the checksums must be calculated after signing.
> >
> > Any idea and feedback is welcome, I think we are not too far from being
> able
> > to release 2.0.0-alpha1!
> >
> > - Xavier
> >
>
>
> --
> Gilles SCOKART
>



-- 
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: release preparation: release guide

[Gilles Scokart <gs...@gmail.com>]

I saw that the example in src/examples/go-ivy/build.xml also mention
the version (and still jayasoft).

Gilles

2007/3/29, Xavier Hanin <xa...@gmail.com>:
> Hi,
>
> To prepare the release, I've created a developer documentation page
> including a release guide. It's already in svn, and will be available on the
> web site in about one hour:
> http://incubator.apache.org/ivy/doc/dev.html
>
> I would like to get some feedback on this doc, to see if it makes sense or
> not (from an Apache but also build and release point of view). One thing I
> still don't know how to address is the case of a vote rejecting the release.
> In this case, we'll need to update something and submit again the release.
> So, is tagging before the vote a good idea, or should we tag only when the
> vote is accepted (note that the release is already build from a branch, so
> it's already safely reproducible)?
>
> Another thing with which I'm not familiar is signing. Do signing files alter
> them? I ask this question because we need to provide checksums for the
> artifacts, so I'd like to add checksum calculation to the release script,
> but since signing occur after the release script, if it alters the artifacts
> the checksums must be calculated after signing.
>
> Any idea and feedback is welcome, I think we are not too far from being able
> to release 2.0.0-alpha1!
>
> - Xavier
>


-- 
Gilles SCOKART