David E Jones wrote:
I guess it depends on what the goal of doing a release is. In my mind
the goal should be to create (over time...) a stable set of artifacts
that people can build and deploy on if they choose not to go with the
latest/greatest.
What you're describing is interesting, but how is that any different
than just using the latest from SVN with a little timing based on
knowing what is going on added in, and keeping a list somewhere of all
non-backwards compatible changes and their revision numbers?
Yes, you have described pretty well what I'm suggesting; I'd only add to
these that we should also create the upgrade services (and/or upgrade
instructions) every time we commit a non-backwards compatible change in
svn. As you said, this is not so different from what we are (implicitly)
suggesting to do right now (as a best practice to stay up-to-date with
the trunk) but I think that it would be nice if the community will
officially support it for a few reasons:
1) it's often difficult for users to pick a 'stable' svn snapshot
2) it's often difficult for users to keep track of important changes
between their revision and the trunk
3) since it is not so different from what we are suggesting right now,
it will not add a huge cost maintaining these extra processes/releases
On that last bit, whatever we do with the releases having an official
wiki page with all non-backward-compatible changes listed on it with the
revision number for each would be a good thing to do...
+1
But, back to the main point: what is the goal of a release in your mind
(and in the mind of anyone else reading in too)?
I'd like to get the opinions from others too.
Personally I think that releases (or release instructions/plans) should
at least help users to keep their system/data in sync with the main
trunk, minimizing the upgrade costs and simplifying the users' decisions
(i.e. "should I upgrade now?").
Of course it would also be great to have a real 'stable' releases (with
patches for them etc...) as you are suggesting (and I really think we
could implement the two approaches simultaneously since what I've
proposed could be the basis of a real release management) but I'm not
sure the community will really maintain them...
Jacopo
-David
