Le 11/09/2011 02:51, sebb a écrit :
On 10 September 2011 21:12, Phil Steitz<phil.ste...@gmail.com> wrote:
On 9/10/11 10:34 AM, sebb wrote:
On 10 September 2011 17:58, Phil Steitz<phil.ste...@gmail.com> wrote:
On 9/10/11 9:21 AM, Ralph Goers wrote:
Are you guys arguing about manifests or build processes. I can't really tell.
There is no perfect build process. I'm not a fan of voting on an RC and then
renaming the tag and so with VFS I created the tag over and over again for each
candidate. That has its own pitfalls but works since Nexus supports it well.
If we were following the Tomcat and Httpd model I think the first release of
VFS 2.0 would have been 2.0.20. I would think that would make it hard for
users to understand what the latest version is, but if it works for them I'd be
interested to know more. Maybe their releases never fail.
I agree with you on this, Ralph. I am not sure it is best for us to
go down the tc/httpd path as it may be confusing to users. What we
IMO it's only confusing if there really are a lot of "missing" releases.
I think Tomcat may do additional checks on the code before putting the
tag up for formal release vote.
This can be done on snapshots or even RCs.
are talking about here is what to put in the manifest of release
jars. If we want to put revision numbers in there (I am personally
not sold on this), the meaningfulness of what we put in will have
impact on the build process. I think it is best to avoid this can
of worms and just either leave the attribute off of release jars (as
it is only really needed for snaps) or put the final release tag
name there. I don't buy the argument that because the release tag
is a copied or moved version of the source used to build the release
jar it is not sufficient to identify the source. I think it should
*definitively* identify the source.
It should, but it doesn't necessarily.
Where exactly? Do we have release tags that do not correspond
exactly with the release sources now? If so, that is a problem that
needs to be fixed.
I'm not saying it has happened, but it could.
There's nothing to stop updates to tags; they can happen accidentally
or maliciously.
Yes, but we also have many eyes looking at svn changes, we have
processed and we have people who can rollback unwanted changes.
I guess our users expect us to do our best to avoid this and to have
reproducible and understandable builds. If it is only a process that say
a tag once voted on should not change and this process is backed up by
the foundation as a whole, it is already something good.
So my point is that both revision numbers or tags could be stored in the
manifest. Tags are easier to understand to users. Revision numbers are
easier for the automated build process. I'm still not sure which one is
better.
Luc
I don't see what the harm is in adding the header line.
If it refers to a revision of a deleted tag, I don't see the point
in it.
AFAIK, you can still extract the code from SVN, even if the tag has
been deleted.
Without the revision, it's impossible to be certain that you have the
correct code.
Phil
Phil
Ralph
On Sep 10, 2011, at 9:04 AM, sebb wrote:
On 10 September 2011 16:28, Phil Steitz<phil.ste...@gmail.com> wrote:
On 9/10/11 8:18 AM, sebb wrote:
On 10 September 2011 16:09, Phil Steitz<phil.ste...@gmail.com> wrote:
Could be I am misunderstanding the proposal here, but IIUC there is another
problem when it comes to release jars. Current practice is to create the jars
from what ends up being the final RC tag. This tag is then either copied or
moved to the release tag, which becomes the definitive source. So at the time
the jar is created, the tag/revision pair that the build number should point to
does not exist. The only choice would seem then to be to reference the RC tag
which may end up deleted. So again, it would seem better to me to either omit
the attribute from release jars or just use the (anticipated) final release tag
name.
Tag rename/copy history unfortunately shows the repo revision at the
time of the copy which makes it quite hard to know what revision was
actually used for the build. You have to scan the history to check for
changes.
The point is just to record what was used to create the jars.
Yes, this will differ from the final tag, but having the information
is better than not having it, IMO.
Not sure I agree. Seems to me the whole point of having a release
tag - the final one that should really be immutable, is that it
points unambiguously to the source used to build the distribution.
Agreed.
Why do we need to complicate things by referencing revision numbers
of (possibly deleted) RC tags?
Because the official release tag was not used to build the project.
The only way to know what was actually used is to record the tag and
revision number.
We don't have to store it in the jar manifests, but that seems as good
a place as any.
Note:
One solution to all this uncertainty is to abandon RCs, and just use
revision numbers.
If the vote fails, bump the revision number and throw away the old
revision and tag. This is what Tomcat and Httpd do.
Can you explain exactly how that works?
This is the process AIUI:
Tag 7.0.22 from trunk; build, vote.
Vote succeeds - release 7.0.22.
Vote fails, create tag 7.0.23 from updated trunk, build and redo vote
Tag 7.0.22 could now be deleted, but I think they keep all the tags.
Their achives [1] for 7.0.x don't contain 13, 17, 18; but the tags [2] do.
[1] http://archive.apache.org/dist/tomcat/tomcat-7/
[2] http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/
Phil
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
