On 12/13/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
My project at work is finally in a place where we really need to use
Shale :-)
That's great!
The 1.0.3 release does not work out of the box for us
because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces
1.1.1.
Is it actually a hard dependency or just what the Maven POM says. Can't say
that I have actually tried that combination.
Shale 1.0.4-SNAPSHOT does not. So I started looking to see
where we stand on publishing a release.
Good. I agree that it's time.
I started in the wiki to see the Release plans and there's not one
for 1.0.4. However, I did see links to Bylaws and Release Guidelines
that don't exist. And I found this:
http://wiki.apache.org/shale/ReleaseGuidelines
The Bylaws and Release Guidelines seem to be something we need to
work out pretty soon - possibly before we release anything else. Am
I correct?
We've been informally following the guidelines that Struts uses, but it'd
definitely be a good idea to formally vote on this.
Getting past that I went to JIRA to see what's to be done before
releasing 1.0.4:
https://issues.apache.org/struts/secure/IssueNavigator.jspa?
reset=true&mode=hide&sorter/order=DESC&sorter/
field=priority&resolution=-1&pid=10130&fixfor=21740
and there's still quite a list. In addition there's tickets that
aren't assigned to a release. So, what has to be done before we can
cut a release?
I just added a "TBD" version that we can use to formally mark issues that we
have considered and decided to keep, but haven't allocated to a particular
release yet. It would be good to go through the list and make a
determination on the unmarked ones -- with the default answer being "put
them in TBD".
If we can narrow it down to a manageable list, I'm willing to help
get the release done so we can depend on something besides a snapshot.
For the issues marked 1.0.4-SNAPSHOT, a couple weeks ago I sent out a nag
email about several of these issues, and there has been some progress made.
Let's get the rest of those cleaned up, either by finishing them or by
reassigning to a later version. If you see unmarked ones you want to work
on, feel free to assign them to yourself and fire away.
One thing that might affect Greg's enthusiasm :-) I'd like to see us do is
try to position for a GA release of everything except shale-tiles, either by
marking it with a separate release grade when we ultimately vote, or by
making it available separately as its own release. I think we can be ready
to have API stability on everything else in just a short while.
Longer term, I'd also like us to think of the following strategy when we do
achieve a 1.0.x GA-graded release:
* Branch the 1.0 codebase at that point
* Start working on 1.1 things on the trunk
* Put new features only into the trunk
* As we fix bugs in the trunk, backport relevant ones to the 1.0 branch
This will give us a straightforward way to do minor bugfix releases on
1.0(or react to a reported security vulnerability, for example),
quickly --
without users having to be concerned about disruption due to new feature
work and bugfix work happening together all the time.
Mixing these things together is a common knock against many open source
projects, as well as being a barrier to getting new releases out the door.
Let's take a page from the HTTPD project in this regard, and be ready to do
bugfix updates on 1.0 while we go crazy on new stuff in 1.1.
Greg
Craig
