Re: [VOTE] Specs organization, versioning, and releasing
On Oct 24, 2006, at 6: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 described here for now and if needed continue discussion and debate about how to handle this better... BUT, I think we must do something now and I think that this is good enough. Jason, I agree. Thanks for sticking with this and seeing it through... --kevan
Re: [VOTE] Specs organization, versioning, and releasing
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 described here
for now and if needed continue discussion and debate about how to
handle this better... BUT, I think we must do something now and I
think that this is good enough.
Here is a tally of the votes cast so far:
+1: jdillon, dblevins, dain, bsnyder, bdudney, gnodet, pmcmahan,
jbohn, rmcguire, hogstrom
+0: jacek
And after some debate:
+1: kevan, alan
While I, djencks, kevan and a few others have expressed some desire
for one version for all specs, and many other have expressed
objection... I do believe that we need to do something to get specs
into a publishable state NOW.
So, unless anyone screams loudly, I am going to implement the changes
described below as an intermediate solution. Once this is done (and
once people comes back to life) we can publish a new set of SNAPSHOT
artifacts and remove the need for the specs build in bootstrap...
which is one step closer to not needing bootstrap.
This may not be the final solution... but its one step closer... and
since we have not moved at all on this for quite some time I think any
movement is better than none at all.
--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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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 we must do something now and I
think that this is good enough.
Here is a tally of the votes cast so far:
+1: jdillon, dblevins, dain, bsnyder, bdudney, gnodet, pmcmahan,
jbohn, rmcguire, hogstrom
+0: jacek
And after some debate:
+1: kevan, alan
While I, djencks, kevan and a few others have expressed some desire
for one version for all specs, and many other have expressed
objection... I do believe that we need to do something to get specs
into a publishable state NOW.
So, unless anyone screams loudly, I am going to implement the changes
described below as an intermediate solution. Once this is done (and
once people comes back to life) we can publish a new set of SNAPSHOT
artifacts and remove the need for the specs build in bootstrap...
which is one step closer to not needing bootstrap.
This may not be the final solution... but its one step closer... and
since we have not moved at all on this for quite some time I think any
movement is better than none at all.
--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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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 new version, it generally means we are fixing a spec compliancy problem. Spec compliancy is a serious issue and we should be doing our best to make sure our users get the fixes quickly. I also think we should be using them internally in our poms for the same reason, so that as people add dependencies on our specs to their projects they don't get into incompatible situations where one of their dependency is using version 1.0.1 and some other dependency is using version 1.0.3. Version ranges will make everyone's life easier. -dain
Re: [VOTE] Specs organization, versioning, and releasing
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 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? You've got my support... :-) One specs version is what I've proposed in the past and would still like to see. I'm generally in favor of it, with the possible exception of the javamail modules, which have shown a bit of churn when compared to the others. Actually, I'm more of the opinion that the javamail spec modules don't really belong bundled with the other specs, because those modules are more implementation code than interface definition. Pure interface specs tend to be a lot more version stable than actual functional code. Rick --kevan
Re: [VOTE] Specs organization, versioning, and releasing
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 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: org.apache.geronimo.specs geronimo-j2ee-connector_1.5_spec [1.0,) 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/ specs/tags/- specs/branches/ 2.
Re: [VOTE] Specs organization, versioning, and releasing
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 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:
org.apache.geronimo.specs
geronimo-j2ee-connector_1.5_spec
[1.0,)
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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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: org.apache.geronimo.specs geronimo-j2ee-connector_1.5_spec [1.0,) 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/ specs/tags/- 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 t
Re: [VOTE] Specs organization, versioning, and releasing
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
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:
org.apache.geronimo.specs
geronimo-j2ee-connector_1.5_spec
[1.0,)
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/
specs/tags/-
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
al
Re: [VOTE] Specs organization, versioning, and releasing
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:
org.apache.geronimo.specs
geronimo-j2ee-connector_1.5_spec
[1.0,)
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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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.
--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:
org.apache.geronimo.specs
geronimo-j2ee-connector_1.5_spec
[1.0,)
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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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: org.apache.geronimo.specs geronimo-j2ee-connector_1.5_spec [1.0,) 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? Seems like we could use that in our own pom.xml files and that would perfectly solve Kevan's original concern: 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, geronimo-spec-jaxr, and geronimo-spec- saaj. It would also address my concerns from eight months ago (which had nothing to do with "easy" vs "hard, btw): On Jan 29, 2006, at 1:41 PM, David Blevins wrote: 1. issuing new versions of jars that don't change creates a confusing mess in public repos and classpaths. 2. snapshots and new jars off all the specs is a terrible way to deal with one or two edge cases of jars that change. Seems both concerns can be met. -David
Re: [VOTE] Specs organization, versioning, and releasing
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:
org.apache.geronimo.specs
geronimo-j2ee-connector_1.5_spec
[1.0,)
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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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 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? You've got my support... :-) One specs version is what I've proposed in the past and would still like to see. --kevan
Re: [VOTE] Specs organization, versioning, and releasing
+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 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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
+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 far we have: +1: jason, dblevins, dain, bsynder, bdudney, gnodet, matt, paul, joe, rick, kevan +0: jacek * * * So, I'm going to commit the changes I have to use the same directory name and artifactId and some pom changes which can be used for any of the release models which we have been talking about. --jason
Re: [VOTE] Specs organization, versioning, and releasing
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, joe, rick, kevan +0: jacek * * * So, I'm going to commit the changes I have to use the same directory name and artifactId and some pom changes which can be used for any of the release models which we have been talking about. --jason
Re: [VOTE] Specs organization, versioning, and releasing
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: geronimo-spec- j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo- spec-saaj. Yup, you'd need to do some manual version bumping for each scenario... except for the one version for all specs scenario. A question for you, Jason: If someone wants to build our released specs from source, what's the process Should just be, check out the tag'd version(s) and mvn install. Granted that if you want to build all of the released versions, that you'd need to svn co each tag. Personally I'd be happy to just have one version for all specs. It does make it easier to release, and to some extent makes it easier on users too, since they don't need to know what the version compatibility is for all other related specs. They can just pick one version and use that for all specs. * * * But... most of the changes that I've got pending can go either way... like using the same directory name as artifactId, site config, etc... I'd still like to commit those soon... even i we are still debating how to manage the versions as a whole. OK, sounds good. +1 --kevan
Re: [VOTE] Specs organization, versioning, and releasing
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, geronimo-spec-jaxr, and geronimo-spec- saaj. Yup, you'd need to do some manual version bumping for each scenario... except for the one version for all specs scenario. A question for you, Jason: If someone wants to build our released specs from source, what's the process Should just be, check out the tag'd version(s) and mvn install. Granted that if you want to build all of the released versions, that you'd need to svn co each tag. Personally I'd be happy to just have one version for all specs. It does make it easier to release, and to some extent makes it easier on users too, since they don't need to know what the version compatibility is for all other related specs. They can just pick one version and use that for all specs. * * * But... most of the changes that I've got pending can go either way... like using the same directory name as artifactId, site config, etc... I'd still like to commit those soon... even i we are still debating how to manage the versions as a whole. --jason
Re: [VOTE] Specs organization, versioning, and releasing
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 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 previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? 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, geronimo-spec-jaxr, and geronimo- spec-saaj. A question for you, Jason: If someone wants to build our released specs from source, what's the process? Maybe I don't understand the proposal, but otherwise IIUC every time we've found a problem in e.g. the jacc spec we'd need to release every spec jar, and update all the versions. I guess we do this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but I think having a lot of identical-contents spec jars would be too confusing. No, I don't think that's what is happening (at least not in theory), but I've never actually "released" specs. So, I may be mistaken... Current Process for updating jacc 1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new geronimoSpecsJaccVersion 2) Update jacc spec sources 3) Build all specs 4) Release jacc and uber-jar spec 5) tag branches/1_1 as tags/1.1.x 6) tag branches/1_1/pom.xml 7) release pom.xml If the version information for any given module is only contained in the parent, we have to release the parent when we release the module. Current Proposed Process 1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec version and new jacc spec version 2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version 3) Update jacc spec sources 4) Build jacc and uber-jar (build seperately or together?). 6) Release jacc 7) tag jacc- 8) Release uber-jar 9) tag uber-jar- Single-version Proposed Process 1) Update branches/1_1_/pom.xml with new specs version 2) Update jacc spec sources 3) Build all specs 4) Release all specs 5) tag branches/1_1 as tags/1.1.x I don't see that releasing identical content spec jars are necessarily confusing (as you point out, we essentially do it with every Geronimo release). Less confusing to have only a single version to worry about... What's the latest release 1.1.x geronimo specs? Use that for all of my j2ee 1.4 spec dependencies. Seems simpler than knowing the latest jacc spec is at version x and the latest servlet 2.4 spec is at version y. Kevan, this question was directed at you. On Aug 21, 2006, at 10:44 PM, David Blevins wrote: This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? Something like: specs/branches/1.1 will remain a more or less "pure" 1.4 level of the specs. specs/branches/1.2 would contain the 1.4 specs and roll-in the Java EE 5 specs as we need and implement them. The geronimo-j2ee_1.4_spec (if we keep it) would contain only 1.4 versions of specs. Java EE 5 specs would stand on their own (e.g. geronimo-ejb_3.0_spec-1.2.0). If we wanted, we could introduce a geronimo-javaee_5_spec (which includes new specs). specs/branches/2.0 would contain only Java EE 5 specs (and any non-EE specs that we're moving forward/maintaining). There is of course, duplication of source (just like you have anytime you branch...) and problems might need to be fixed in (and released from) multiple branches). --kevan
Re: [VOTE] Specs organization, versioning, and releasing
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 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 previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? 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, geronimo-spec-jaxr, and geronimo-spec- saaj. A question for you, Jason: If someone wants to build our released specs from source, what's the process? Maybe I don't understand the proposal, but otherwise IIUC every time we've found a problem in e.g. the jacc spec we'd need to release every spec jar, and update all the versions. I guess we do this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but I think having a lot of identical-contents spec jars would be too confusing. No, I don't think that's what is happening (at least not in theory), but I've never actually "released" specs. So, I may be mistaken... Current Process for updating jacc 1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new geronimoSpecsJaccVersion 2) Update jacc spec sources 3) Build all specs 4) Release jacc and uber-jar spec 5) tag branches/1_1 as tags/1.1.x 6) tag branches/1_1/pom.xml 7) release pom.xml If the version information for any given module is only contained in the parent, we have to release the parent when we release the module. Current Proposed Process 1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec version and new jacc spec version 2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version 3) Update jacc spec sources 4) Build jacc and uber-jar (build seperately or together?). 6) Release jacc 7) tag jacc- 8) Release uber-jar 9) tag uber-jar- Single-version Proposed Process 1) Update branches/1_1_/pom.xml with new specs version 2) Update jacc spec sources 3) Build all specs 4) Release all specs 5) tag branches/1_1 as tags/1.1.x I don't see that releasing identical content spec jars are necessarily confusing (as you point out, we essentially do it with every Geronimo release). Less confusing to have only a single version to worry about... What's the latest release 1.1.x geronimo specs? Use that for all of my j2ee 1.4 spec dependencies. Seems simpler than knowing the latest jacc spec is at version x and the latest servlet 2.4 spec is at version y. Kevan, this question was directed at you. On Aug 21, 2006, at 10:44 PM, David Blevins wrote: This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? Any thoughts? -David
Re: [VOTE] Specs organization, versioning, and releasing
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 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 previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? 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, geronimo-spec-jaxr, and geronimo-spec- saaj. Can we use version ranges to address this issue? -dain
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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 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 previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? 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, geronimo-spec-jaxr, and geronimo-spec- saaj. A question for you, Jason: If someone wants to build our released specs from source, what's the process? Maybe I don't understand the proposal, but otherwise IIUC every time we've found a problem in e.g. the jacc spec we'd need to release every spec jar, and update all the versions. I guess we do this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but I think having a lot of identical-contents spec jars would be too confusing. No, I don't think that's what is happening (at least not in theory), but I've never actually "released" specs. So, I may be mistaken... Current Process for updating jacc 1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new geronimoSpecsJaccVersion 2) Update jacc spec sources 3) Build all specs 4) Release jacc and uber-jar spec 5) tag branches/1_1 as tags/1.1.x Current Proposed Process 1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec version and new jacc spec version 2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version 3) Update jacc spec sources 4) Build jacc and uber-jar (build seperately or together?). 6) Release jacc 7) tag jacc- 8) Release uber-jar 9) tag uber-jar- Single-version Proposed Process 1) Update branches/1_1_/pom.xml with new specs version 2) Update jacc spec sources 3) Build all specs 4) Release all specs 5) tag branches/1_1 as tags/1.1.x I don't see that releasing identical content spec jars are necessarily confusing (as you point out, we essentially do it with every Geronimo release). Less confusing to have only a single version to worry about... What's the latest release 1.1.x geronimo specs? Use that for all of my j2ee 1.4 spec dependencies. Seems simpler than knowing the latest jacc spec is at version x and the latest servlet 2.4 spec is at version y. --kevan
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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 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 update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? -David
Re: [VOTE] Specs organization, versioning, and releasing
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 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 update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? -David
Re: [VOTE] Specs organization, versioning, and releasing
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 update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This just came into mind. Any thoughts on what we'd do for the specs that are javaee 5 only versions (corba, servlet, soon jta and ejb, etc.) and the ones that overlap between j2ee 1.4 and javaee 5 like jms, jca and jacc? -David
Re: [VOTE] Specs organization, versioning, and releasing
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 not convinced that this really makes things any better... I agree that your plan is better than the previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? Maybe I don't understand the proposal, but otherwise IIUC every time we've found a problem in e.g. the jacc spec we'd need to release every spec jar, and update all the versions. I guess we do this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but I think having a lot of identical-contents spec jars would be too confusing. thanks david jencks -David
Re: [VOTE] Specs organization, versioning, and releasing
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 better... I agree that your plan is better than the previous plan for multiple trunks, but I'm not convinced that either plan is actually making things simpler... If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname, and servlet upon which it depends? So, haven't we just split apart the specification of these version dependencies from a single pom.xml into multiple poms? Is this really making things simpler? That'd be right. I'm not sure how complicated that is, though. None of those specs have changed in a year. Can you give an non- hypothetical example of something that does change and causes this problem that isn't the J2EE uber-jar? -David
Re: [VOTE] Specs organization, versioning, and releasing
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 update to the 1.2.0 specs are required, release a 1.2.1 version of all specs (even if some of the 1.2.1 versions are identical to their 1.2.0 version). This is definitely the easiest path. Not sure however that folks would be happy about this though... --jason
Re: [VOTE] Specs organization, versioning, and releasing
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 previous plan for multiple
trunks, but I'm not convinced that either plan is actually making
things simpler...
If I understand your proposal, tags/geronimo-spec-jaxrpc-rpcversion>/pom.xml will specify the tagged versions of saaj, qname,
and servlet upon which it depends? So, haven't we just split apart
the specification of these version dependencies from a single pom.xml
into multiple poms? Is this really making things simpler?
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 update to the 1.2.0 specs are
required, release a 1.2.1 version of all specs (even if some of the
1.2.1 versions are identical to their 1.2.0 version).
--kevan
On Aug 18, 2006, at 7: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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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/ specs/tags/- specs/branches/ What is the layout for branches? Right now it is the major version with all the specs underneath it. For instance, there is 1_1, 1_1_1 (not sure why we use _'s here and .'s elsewhere). branches would follow the same layout like: specs/branches/geronimo-activation_1.0.2/1_1 as opposed to specs/ branches/1_1/geronimo-activation_1.0.2. Or do you intend to leave branches alone? I don't plan to touch branches for now... if I did do something I would change '_' to '.' I think that we need to evaluate how to best organize branches based on the new release scheme when it comes time to need a branch. --jason
Re: [VOTE] Specs organization, versioning, and releasing
[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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
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/
specs/tags/-
specs/branches/
What is the layout for branches? Right now it is the major version with all the specs underneath
it. For instance, there is 1_1, 1_1_1 (not sure why we use _'s here and .'s elsewhere). branches
would follow the same layout like:
specs/branches/geronimo-activation_1.0.2/1_1 as opposed to
specs/branches/1_1/geronimo-activation_1.0.2.
Or do you intend to leave branches alone?
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
Re: [VOTE] Specs organization, versioning, and releasing
Jason Dillon wrote:
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/
specs/tags/-
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 affects tags primarily... as a side effect of how each module
will be released.
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.
Currently, the release process is to publish a candidate release, test
it,
and once approved, move the *same* binaries to the distribution site.
Using the maven release plugin means that we will vote on a SNAPSHOT
and that plugin will upload new binaries with the release version.
Is that really what's wanted ?
I'm not sure that there is going to be a high barrier to releasing spec
jars (they are not quite the same as a server assembly)... and IMO it is
fine to vote (if needed) on the SNAPSHOT and then let the release plugin
make the release artifacts.
The only issue I see is if the final binaries are different other than removing the SNAPSHOT. I
know its all supposed to work but stranger things have happened. I guess that's the release
manager's job :)
--jason
Re: [VOTE] Specs organization, versioning, and releasing
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/
>> specs/tags/-
>> 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 affects tags primarily... as a side effect of how each module
will be released.
>> 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.
>
> Currently, the release process is to publish a candidate release,
> test it,
> and once approved, move the *same* binaries to the distribution site.
> Using the maven release plugin means that we will vote on a SNAPSHOT
> and that plugin will upload new binaries with the release version.
> Is that really what's wanted ?
I'm not sure that there is going to be a high barrier to releasing
spec jars (they are not quite the same as a server assembly)... and
IMO it is fine to vote (if needed) on the SNAPSHOT and then let the
release plugin make the release artifacts.
Ok, I agree for specs.
I was mainly thinking about the server ...
--jason
--
Cheers,
Guillaume Nodet
Re: [VOTE] Specs organization, versioning, and releasing
On Aug 20, 2006, at 1:37 AM, Guillaume Nodet wrote:
specs/trunk/pom.xml
specs/trunk/
specs/tags/-
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 affects tags primarily... as a side effect of how each module
will be released.
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.
Currently, the release process is to publish a candidate release,
test it,
and once approved, move the *same* binaries to the distribution site.
Using the maven release plugin means that we will vote on a SNAPSHOT
and that plugin will upload new binaries with the release version.
Is that really what's wanted ?
I'm not sure that there is going to be a high barrier to releasing
spec jars (they are not quite the same as a server assembly)... and
IMO it is fine to vote (if needed) on the SNAPSHOT and then let the
release plugin make the release artifacts.
--jason
Re: [VOTE] Specs organization, versioning, and releasing
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/
specs/tags/-
specs/branches/
I guess I missed something, but what's the difference compared to the
current layout ? This only affect the tags, right ?
+1
2. Each plugin will continue to have its own version and will be
released independently.
+1
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.
+1
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.
Currently, the release process is to publish a candidate release, test it,
and once approved, move the *same* binaries to the distribution site.
Using the maven release plugin means that we will vote on a SNAPSHOT
and that plugin will upload new binaries with the release version.
Is that really what's wanted ?
5. Change all module directories to match artifactIds.
+1
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
--
Cheers,
Guillaume Nodet
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
[X] 0 No opinion Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Specs organization, versioning, and releasing
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/
specs/tags/-
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)
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
Re: [VOTE] Specs organization, versioning, and releasing
+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/
specs/tags/-
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
