On 12/3/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
release early, release often!
i understand and agree with the reasons behind the 'no releases rule'
but wonder whether team labs may need to consider how they will
interpret this rule and offer some documented guidelines.
people disagree about what a release is
IMO a release is fundamentally just a line in the sand: a tag in
subversion. what matters is the source. everything else is just
packaging.
so (for me) a literal reading of the 'no release' rule excludes all
tags from the apache repository
this leads on the issue of offshore tags and releases. one approach
for those who need releases would be to use subversion to create
offshore tags. a more radical approach would be to cut releases
offshore.
given that maven requires released dependencies, i suspect that these
issues are going to have to be tackled sooner or later.
opinions?
Personally, I think this is going to have to be one of those things
where there's a continuum along which the projects exist. As they
start, projects are likely to not have any releases at all.
Eventually, it's only natural for them to start tagging particular
versions, so that the brave few who are using the code can at least
have some idea what versions it's relatively safe to work from. When
they hit the point where there are enough users that having actual
tarballs and whatnot makes sense, it's probably time to move out of
the labs and into the incubator.
So, FWIW I'd recommend that the projects we have in labs now migrate
to a repository layout that includes the trunk/tags/branches
directories, so that in the future they're able to start tagging, etc.
It's better than the alternative, just having them record rev numbers
in their CHANGES file or something, and I expect that's what they'd
eventually end up doing anyway.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
