On 06/23/2011 07:18 PM, Franklin, Matthew B. wrote:
On 6/23/11 12:47 PM, "Marlon Pierce"<[email protected]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How close are we to having the 0.1-INCUBATING release complete? There
are a lot of patches and other commits that are on hold. Should we make
a branch?
IMHO, No. I have been tied up all week, but just broke free and I should
be able to get the artifacts out for vote this week.
One question for Ate, or someone else familiar with the process. It was
mentioned that we could push the button on the master and project releases
at the same time, but if the rave-project depends on the released master,
how would this work?
Hi Matt,
You (automatically) opened a Nexus staging repository when you initiated the
release for the rave-master project.
As long as you keep that staging repository "open", it'll will accept following
rave project releases (*only* from you as you are the "owner"), until you
"close" that repository. So you can bundle multiple release artifacts into one
staging repository that way.
After you have closed the stating repository, which will make it publicly
accessible so everyone can "evaluate" it, there are two possible usages: -
- "release" or "deploy", pushing the artifacts into Maven Central
- "drop", delete the staging repository (e.g. after the release voting failed)
By combining both rave-master and rave-project in a single staging repository
you allow (force!) them to be voted upon together, e.g. through a single VOTE.
Note: the binary demo .zip/.tar.gz distributions are not pushed through the
Maven repository so need a separate upload to a temporary location, but IMO
should also be added to this single VOTE, as they together constitute the rave
0.1-incubating release.
Also note that the potential downside of this is that if for instance the
rave-project contains a blocking error causing the vote to fail, it will
automatically also fail the rave-master 0.1-incubating release...
But as the need to release the rave-master is/should become much less over time,
this combined releasing will likely also occur less often.
Technically, before you can start the release of rave-project, you'll have to
manually update (and first commit) the reference to rave-master-0.1-incubating.
This also means you'll need this rave-master version already available in your
local repository (which you already have as its release manager).
Thereafter, start (ASAP) the rave-project release and thereby push it into the
staging repository.
CAVEAT: as long as the staging repository isn't released (e.g. at a minimum 72
hours later), the current rave-project trunk (then at 0.2-incubating-SNAPSHOT)
will have a reference to a rave-master-0.1-incubator *which isn't publicly
available* yet, which will cause builds to fail (e.g. like Hudson)!
There are two ways to fix this:
- quickly update and commit using rave-master-0.2-incubating-SNAPSHOT, or
- *temporary* add the temporary staging repository (after you closed it)
*and* remove it again as soon as the release is available at Maven Central
I think this should cover it all, otherwise ping me later today.
Ate
-Matt
Marlon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOA24jAAoJEEfVXEODPFIDbS0H/Rh/4QrTO6GedMmVDOzsxChG
qOS8/OjAoqGT3afP+ixtOrlNuZ8f91SrlSDbnNEa09gskgO6SrI+A9PmzRCvRt/6
iePErogIADyd3krs8zl89VtcRQODT5dgWruKAYA+VZsgj9mjP4bBt0ZRDYCsUoGx
pcpb/HnjyEHWz9JHz7jIh6vwgtsKIlnUmmtve2yJcgu3GD3dsCHcDd3lCPi3EAlf
BmlUzXcuCNRCq/Rrgni+xkDnh24pgRrmxqv/eykBlkXQqjm48Uio3WWpGkzmOn/O
7uJDqlKSb847pnteWG1lAlBVwkFoBltCqeqpEX4rhULhjqgSA747tvFSg5q1uyk=
=MFK1
-----END PGP SIGNATURE-----
