Folks... this vote has been lingering for way to long... some of the
in-flight debate/discussion kinda threw us off track.
I believe that we should implement the solution we have described here
for now and if needed continue discussion and debate about how to
handle this better... BUT, I think
The vote seems to have passed. Go for it!
Regards,
Alan
On Oct 24, 2006, at 3:53 PM, Jason Dillon wrote:
Folks... this vote has been lingering for way to long... some of the
in-flight debate/discussion kinda threw us off track.
I believe that we should implement the solution we have
Kevan Miller wrote:
On Aug 27, 2006, at 7: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
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.
Regardless of the layout we choose, we should be encouraging our
users to specify the spec version using a version range, because if
we are releasing a
+1 to releasing them all as one version #.
It will make everyones life easier (dev's and users) having one # to
remember than many.
TTFN,
-bd-
On Aug 27, 2006, at 5:50 PM, Jason Dillon wrote:
I've implemented #5, which was to restructure to use the same
directory and artifactIds... I
On Aug 27, 2006, at 7: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
On Aug 28, 2006, at 10:51 AM, Dain Sundstrom wrote:
but for maven users I don't think either matters since you can
simply use a version range dependency like this:
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
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
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
The pom is part of the release.
--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
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
My preference is to treat specs like any other top-level project,
like server, xbean, gbuild, etc...
and that to means one version for all of the modules.
--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
I still think that releasing each spec module individual adds
complexity... and IMO is not worth it.
--jason
On Aug 28, 2006, at 8:41 PM, David Blevins wrote:
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
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.
+1 I thought that I already voted on this.
Regards,
Alan
Jason Dillon wrote:
Okay, since there is still some debate about how to actually release
these modules, I am going to commit some partial work to clean up the
project and we can continue to discus how the release will be made.
So
Okay, since there is still some debate about how to actually release
these modules, I am going to commit some partial work to clean up the
project and we can continue to discus how the release will be made.
So far we have:
+1: jason, dblevins, dain, bsynder, bdudney, gnodet, matt, paul,
Close our eyes?
Why should it matter? They can all live in the same tree... just
some with 1.5 and some with 1.4 compiles.
--jason
On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of
On Aug 21, 2006, at 11:09 PM, Jason Dillon wrote:
Close our eyes?
Why should it matter? They can all live in the same tree... just
some with 1.5 and some with 1.4 compiles.
I think you read the email too fast :)
-David
--jason
On Aug 21, 2006, at 10:44 PM, David Blevins wrote:
On
+1
Jason Dillon 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.
On Aug 22, 2006, at 1:37 AM, David Jencks wrote:
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g.
javamail depends on activation; jaxrpc on saaj, qname, and
servlet; and
+1.
Jason Dillon 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.
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
On Aug 22, 2006, at 1:37 AM, David Jencks wrote:
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g.
javamail depends on
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
On Aug 22, 2006, at 1:37 AM, David Jencks wrote:
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g.
javamail depends on
On Aug 22, 2006, at 12:45 PM, David Blevins wrote:
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
On Aug 22, 2006, at 1:37 AM, David Jencks wrote:
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
Well, the current activation spec is at version 1.1. When that
version was bumped from 1.0 (or 1.0.x), you'd have needed to know/
remember to change the poms in the following specs: geronimo-spec-
j2ee, geronimo-spec-javamail,
On Aug 22, 2006, at 7:03 PM, Jason Dillon wrote:
On Aug 22, 2006, at 6:24 AM, Kevan Miller wrote:
Well, the current activation spec is at version 1.1. When that
version was bumped from 1.0 (or 1.0.x), you'd have needed to know/
remember to change the poms in the following specs:
Jason Dillon wrote:
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
I guess I missed something, but what's the difference compared to the
current layout ? This only affect the
Jason Dillon 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/
What
+1
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
[X] +1 Allow changes
Joe
Jason Dillon 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
On Aug 21, 2006, at 6:55 AM, Matt Hogstrom wrote:
Jason Dillon 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
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm not
convinced that this really makes things any better...
I agree that your plan is better than the
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of versioning
we're trying to apply to specs... I wonder if the simplest course
of action is to stop releasing individually versioned specs, and
instead always release all specs. When an
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm not
convinced that this really makes things any
On Aug 21, 2006, at 9:21 PM, David Blevins wrote:
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
As long as we have inter-dependencies between specs (e.g. javamail
depends on activation; jaxrpc on saaj, qname, and servlet; and
especially geronimo-spec-j2ee depends on everything), I'm
On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote:
I think the source of complexity is the granularity of versioning
we're trying to apply to specs... I wonder if the simplest course
of action is to stop releasing individually versioned specs, and
instead always release all specs. When an
On 8/19/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
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
I guess I missed something, but what's the difference compared to the
current layout ? This only affect the tags, right ?
Yes, it
On 8/20/06, Jason Dillon [EMAIL PROTECTED] wrote:
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
I guess I missed something, but what's the difference compared to the
current
+1
-dain
On Aug 18, 2006, at 4:53 PM, Jason Dillon 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
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
[X] 0 No opinion
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
+1
On Aug 18, 2006, at 5:53 PM, Jason Dillon 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
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
+1
--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
+1
-David
On Aug 18, 2006, at 4:53 PM, Jason Dillon 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
46 matches
Mail list logo
