On Aug 28, 2006, at 7:49 PM, Jason Dillon wrote:
The pom is part of the release.
On Aug 28, 2006, at 7:46 PM, David Blevins wrote:
The only reason we've had to re-release these is because the poms
of a couple have changed. We can fix that with version ranges.
Meaning, if we add version ranges to our poms when they refer to
other specs, we don't need to re-release them when those other specs
change.
-David
--jason
On Aug 28, 2006, at 7:46 PM, David Blevins wrote:
On Aug 28, 2006, at 5:50 PM, Jason Dillon wrote:
I don't think that using version ranges really helps make
anything easier or simpler.
How is it confusing to have just one version number for all
specs? Anything else seems to induce much more confusion, for us
and them.
If the confusion is... "why is there a new version for a jar that
did not change" I point you back at my example of Geronimo and
releasing bug fix versions... where say 80% of the modules will
have a new version but no changes. Does this also confuse
users? If so, then we need to educate our users and not try to
dance around their ignorance and complicate our build release
management.
I've intentionally not made any statements of what is "easy" and
you're countering arguments I've never made.
The following specs haven't changed in a 1-2 years and don't need
to be released:
geronimo-ejb_2.1_spec
geronimo-j2ee-connector_1.5_spec
geronimo-j2ee-deployment_1.1_spec
geronimo-j2ee-jacc_1.0_spec
geronimo-j2ee-management_1.0_spec
geronimo-jaxr_1.0_spec
geronimo-jaxrpc_1.1_spec
geronimo-jms_1.1_spec
geronimo-jsp_2.0_spec
geronimo-jta_1.0.1B_spec
geronimo-qname_1.1_spec
geronimo-saaj_1.1_spec
geronimo-servlet_2.4_spec
The only reason we've had to re-release these is because the poms
of a couple have changed. We can fix that with version ranges.
-David
--jason
On Aug 28, 2006, at 10:51 AM, Dain Sundstrom wrote:
I am starting to get dizzy from this discussion...
I remember the original argument for switching to individually
versioned specifications was to avoid republishing specs like
javax.ejb repeatedly as it confused users to have new version
numbers that don't change. The counter argument is that having
lots of different version numbers is difficult for users as they
will have to know the version of every jar.
I think both concerns are important, but for maven users I don't
think either matters since you can simply use a version range
dependency like this:
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-j2ee-connector_1.5_spec</artifactId>
<version>[1.0,)</version>
</dependency>
This gives you the most resent published version of the
connector 1.5 spec (BTW I tried this out in the jencks project
and it worked perfectly). Either solution for a maven user
shouldn't be a problem.
So I think that leaves us with the question what is going to be
easiest and quickest layout for us to release when we find a
spec bug?
-dain
On Aug 27, 2006, at 4:50 PM, Jason Dillon wrote:
I've implemented #5, which was to restructure to use the same
directory and artifactIds... I renamed the directories to match.
I think we need to have another round of discussion on how to
handle
the versioning.
I'm starting to lean heavily towards having *one* version for
*all* of
the specs. I don't care too much that if spec A makes a change
that
we release new versions of all of the other specs. It is actually
similar to the server, when a bugfix release is made, a bunch of
modules will have no change since the last version, but we release
them anyways because it is simpler for use to manage, and
easier for
users too, since they just need to know one version number...
not the
version number of each module.
IMO, less version numbers to manage is easier... and better.
The side
effect is that more artifacts get released when we cut a new
version.
But I don't see that we are going to be making tons of these spec
releases... so I don't see any harm in the additional artifacts.
So, my recommendation is to use one version for all of them. I
believe this will be best in the short to medium term at least,
and if
we find that it not working for the long run, then we can revisit
later. But right now I'd like to get a consistent release of
these
artifacts so we can remove the need for the bootstrap step to
check
them out and build them.
I'd like to discus for a few days, create a new proposal, vote and
then implement in the near future.
Comments?
--jason
On 8/18/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches
+tags.
There will instead be one trunk+branches+tags for all specs
laid out
as follows:
specs/trunk/pom.xml
specs/trunk/<artifactId>
specs/tags/<artifactId>-<version>
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in
that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major
change
to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out
all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
