On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
Dain ran into a similar problem where while releasing he had an
issue that a utility as part of the release process caused him to
make a change to source because of a variable name.
Was this before or after the release tag was made? Can you elaborate
on this? Or maybe Dain can, so that I can understand better.
I know of several issues with the release plugin, I actually think
that its only useful as part of an automated release solution, still
need some additional build help and sanity checks to ensure that when
its time to make a release, that everything is going to be happy.
For the milestone I'm not concerned but I am concerned that we get
the release process documented and agreed to. We're not going to
fix these two release processes.
I agree, though I hope we can fix some of these issues before M2
goes out.
My point about the ci to tags however could have been avoided, by
keeping the branch (not moving it to tags) and then copying to label,
as is the recommended method to label things in svn. It was also
more general that relating to releases... generally assume that a tag
is read-only. Don't mv a branch to a tag, copy it.
I am writing up on the CWiki my thoughts for release that I'd like
to get ironed out BEFORE we get to the next release. Not that
we've done anything wrong but I feel this process is too fluid as
we've changed it almost every release. This includes changes to
voting, releasing, and build tools. We've worked through them each
time and no process will be perfect but we should be refining
something each time and not creating something new.
Well, I think a ci to a tag *was* wrong :-P But other than that I
basically agree.
Here are my list of items to start with:
Define release in terms of Milestone, Beta, Full Version
- includes definition of user expectations
- quality of the release
Yikes... not sure what either of these might actually be... can you
give an example of what these might look like for 2.0-M1?
- logging level consistency
Um... you know that this one will differer based on which user
consumes it right? Open-source-savvy user might expect INFO, where
Joe-consumer-embedder, might expect its ERROR (and both may flag it
as broke if its not what they expected).
Not sure who the default release configuration should be tailored
to... and god no... I'm not suggesting we make a release for each of
them :-P
- Release Notes content
Yes, this is important... and IMO should be driven off of JIRA for
that version as well as including detail about specific changes.
I think that the AMQ folks do this well... as well as that Atlassian
folks. I recommend we copy them.
- Packing list for delivered content
Eh, I don't care too much about this really. Though if it can be
automated, then maybe it okay, else I see this as a non-important
document which will quickly become out of date, and out of date
documented is more harmful than it is useful. Though a general
README.txt which explains the basic top-level directories should be
good, and easy to maintain.
- Naming conventions for delivered modules (ala manually created
source)
Process of branching and tagging (we already have a plethora of
discussion...I think this needs to get on a Wiki)
- includes tags and modifications
Yes, it should... though the svn book covers most of this, I don't
recommend we drift to far from it.
Including non-released artifacts and how they are handeled and
where they go
Its been almost 6 months and I am still staying the same thing... we
need our own repo, backed our svn, which can contain these bits... as
the time to wait for other projects to release is crazy (especially
if they too are ASF projects bound by the same style of release hell).
Having our own svn backed repo allows us to always have the right
versions of artifacts, labeled with our source, which helps increase
the changes that codelines are buildable far into the future. And
even if our repo is only subset, and the rest are pulled from central
for starting out, we are in a better position. Even better to have
*everything* in our svn repo, but that might be more work to
implement than any of us have time right now.
Voting time lines and expectations
- Things like VOTE and DISCUSS threads
- when do they get restarted (or do they)...how to handle issues
like changes to the tree that were no previously caught
- Is there a limit where the 72 hour timeline is satisfied previously?
NOTE, if our release process was automated, then the time/effort to
build a release would be minimal. We could easily spin off a
"<version>-VOTING-<n>" build, and then once it passes, simply rebuild
the exact same thing as a final. This is one significant advantage
to building off of source control (either be it sources, or binaries
checked in). But with that and an automated process, you can take a
previous VOTING build and reproduce it exactly, changing only the
version... and have a high degree of trust that it is going to behave
the same... backed up by svn's change logs to show what was actually
changed.
I still think the whole voting delay is silly... but oh well... I
guess it similar to cutting a build for QA, then QA pounds on it for
a week, and either blesses or rejects it. But IMO that happens
before a "release", when it comes time to actually make a release, it
should already have passed the requirements, voting, blah, blah. And
you simply rebuild the project from the revision that has been
officially blessed. IMO it is backwards to bless the binaries...
when it should be the source code that is blessed.
--jason
