You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2006/12/11 19:13:21 UTC
[DISCUSS] specs versioning
The versioning policy for our geronimo specs has been floating around
for a while now. I'd like to see this issue resolved.
There have been two approaches discussed
1) Single version -- all specs are released under the same version
number.
2) Separate version -- each spec is versioned separately from the
other specs.
Dain created a review of the two proposals in the wiki -- http://
cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think
you can quibble over a few of the details, but it does a good job at
summarizing the issue.
IMO, there are going to be drawbacks no matter which approach we
take. However, I'm going to be happy with either approach as long as
we reach a *decision*. I'd prefer that we reach consensus on this
discussion thread. However, if necessary, we can vote on the issue.
Personally, I think we should use a single version for releasing our
specs. I think this makes it easier for us as developers in managing
spec releases. I think users will find it easier to collect a
consistent set of specifications. I think these benefits outweigh
concerns over the lack of flexibility and the wasteful aspects of re-
releasing unchanged specifications.
I suppose there's a hybrid option where we release separate versions,
now, and move to a single version policy (2.0?) for our next release.
--kevan
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
I agree that parts of server should be split up into a few smaller
chunks... but I can tell you from current experience with what we
have so far, and from past experence where I worked on systems larger
than G with each bit versioned separately... that the more versions
you put in the mix, the more work and headache it is going to be to
keep the system in order.
The less versions to manage the better... that does not mean only one
version for everything, but a limited number of components that are
managed and versioned together. IMO specs are one of those
components that should be managed and versioned together.
I do not think we want to end up with the same cluster* that maven
exists in today with all of its components, some from ASF, some from
Codehaus, all versioned up separately, can't easily tell which
versions are compatible with each other, can't tell which is the
latest. I think following maven's practice would be a huge mistake.
--jason
On Dec 11, 2006, at 5:34 PM, Dain Sundstrom wrote:
> On Dec 11, 2006, at 1:55 PM, Jason Dillon wrote:
>
>> On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
>>> In that case, why not move specs into the server tree?
>>
>> Why not version each module in the server tree separately?
>
> Because many of the server modules are HIGHLY coupled which makes
> releasing them independently very difficult. For the modules that
> are independently useful and not highly coupled, I think we should
> version them independently (but not in "modules").
>
> -dain
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 1:55 PM, Jason Dillon wrote:
> On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
>> In that case, why not move specs into the server tree?
>
> Why not version each module in the server tree separately?
Because many of the server modules are HIGHLY coupled which makes
releasing them independently very difficult. For the modules that
are independently useful and not highly coupled, I think we should
version them independently (but not in "modules").
-dain
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
> In that case, why not move specs into the server tree?
Why not version each module in the server tree separately?
--jason
Re: [DISCUSS] specs versioning
Posted by David Blevins <da...@visi.com>.
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote:
> On 12/11/06, Dain Sundstrom <da...@iq80.com> wrote:
>> On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
>>
>> > I'm in favor of a single version for all specs. Versioning the
>> specs
>> > individually has some advantages but makes the release manager's
>> job
>> > more difficult since the tooling doesn't readily support that
>> > approach.
>>
>> Um.. that's not true. Maven has full support for this. Also it
>> doesn't make the release manager's job harder.
>
> Maybe I read too much into the wiki page that Kevan referenced, which
> lists the following advantage for using a single version for specs:
> - Release process is simple and can be fully automated with the
> release plugin
>
> And the following listed as a disadvantage of versioning the specs
> individually:
> - Releases are more difficult because the person performing the
> release must be aware of any dependencies and must also rerelease
> those jars. (eliminated with working version-ranges)
That's actually not true as you can mark all the deps of a spec as
'<scope>provided' which shuts off maven's transitivity. Then all
this pom interlinking between specs which makes everyone's brain hurt
just goes away.
-David
> and lists as a supporting fact:
> - Version ranges don't work several (most?) important maven plugins
>
> Is the wiki page outdated or am I missing the point?
>
>> > And as a developer (at least for me) a single version is
>> > more intuitive, evidenced by my recent snafu where I created the
>> > initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason
>> > keeps a very close eye on things and suggested using 1.0-SNAPSHOT
>> > instead.
>>
>> Um I think that goes both ways. Because all specs are currently at
>> 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As
>> specs become more independent, I would expect you would naturally
>> choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not
>> come along that often so making a mistake once a year is not a big
>> deal.
>
> I agree that could go either way. Besides, what seems intuitive for
> me usually ends up getting me into trouble so I shouldn't have even
> brought it up. :-)
>
>> > I also believe having the specs all at a single release is
>> consistent
>> > with the approach we use in server/trunk, where the artifacts share
>> > the same geronimo version and when necessary a version number
>> can be
>> > included in the artifactId. Consistency has its benefits.
>>
>> In that case, why not move specs into the server tree?
>
> So a single version of specs can support more than one version of the
> server. Would that not be the case with the 1.2 and 2.0-M1 versions
> of the server?
>
>>
>> -dain
>>
>>
>
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote:
> On 12/11/06, Dain Sundstrom <da...@iq80.com> wrote:
>> On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
>>
>> > I'm in favor of a single version for all specs. Versioning the
>> specs
>> > individually has some advantages but makes the release manager's
>> job
>> > more difficult since the tooling doesn't readily support that
>> > approach.
>>
>> Um.. that's not true. Maven has full support for this. Also it
>> doesn't make the release manager's job harder.
>
> Maybe I read too much into the wiki page that Kevan referenced, which
> lists the following advantage for using a single version for specs:
> - Release process is simple and can be fully automated with the
> release plugin
>
> And the following listed as a disadvantage of versioning the specs
> individually:
> - Releases are more difficult because the person performing the
> release must be aware of any dependencies and must also rerelease
> those jars. (eliminated with working version-ranges)
I thought you were referring to the Geronimo server releases. Yes
the above is true for releasing specs, but releasing specs is a very
rare thing since specs are rarely added or removed.
> and lists as a supporting fact:
> - Version ranges don't work several (most?) important maven plugins
>
> Is the wiki page outdated or am I missing the point?
Nope that is accurate.
>> > I also believe having the specs all at a single release is
>> consistent
>> > with the approach we use in server/trunk, where the artifacts share
>> > the same geronimo version and when necessary a version number
>> can be
>> > included in the artifactId. Consistency has its benefits.
>>
>> In that case, why not move specs into the server tree?
>
> So a single version of specs can support more than one version of the
> server. Would that not be the case with the 1.2 and 2.0-M1 versions
> of the server?
I was being a devil's advocate. In general, once we release a spec
is should never change (i.e., should be 1.0 forever). Only in the
rare case where we find bugs in a spec would we release an update.
In that case, the specs would support all versions of the server that
need that spec, another project using our specs, and any user
applications using our specs.
-dain
Re: [DISCUSS] specs versioning
Posted by Paul McMahan <pa...@gmail.com>.
On 12/11/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
>
> > I'm in favor of a single version for all specs. Versioning the specs
> > individually has some advantages but makes the release manager's job
> > more difficult since the tooling doesn't readily support that
> > approach.
>
> Um.. that's not true. Maven has full support for this. Also it
> doesn't make the release manager's job harder.
Maybe I read too much into the wiki page that Kevan referenced, which
lists the following advantage for using a single version for specs:
- Release process is simple and can be fully automated with the release plugin
And the following listed as a disadvantage of versioning the specs individually:
- Releases are more difficult because the person performing the
release must be aware of any dependencies and must also rerelease
those jars. (eliminated with working version-ranges)
and lists as a supporting fact:
- Version ranges don't work several (most?) important maven plugins
Is the wiki page outdated or am I missing the point?
> > And as a developer (at least for me) a single version is
> > more intuitive, evidenced by my recent snafu where I created the
> > initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason
> > keeps a very close eye on things and suggested using 1.0-SNAPSHOT
> > instead.
>
> Um I think that goes both ways. Because all specs are currently at
> 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As
> specs become more independent, I would expect you would naturally
> choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not
> come along that often so making a mistake once a year is not a big deal.
I agree that could go either way. Besides, what seems intuitive for
me usually ends up getting me into trouble so I shouldn't have even
brought it up. :-)
> > I also believe having the specs all at a single release is consistent
> > with the approach we use in server/trunk, where the artifacts share
> > the same geronimo version and when necessary a version number can be
> > included in the artifactId. Consistency has its benefits.
>
> In that case, why not move specs into the server tree?
So a single version of specs can support more than one version of the
server. Would that not be the case with the 1.2 and 2.0-M1 versions
of the server?
>
> -dain
>
>
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I care but don't have the brain power or will to comment tonight.
On Dec 11, 2006, at 9:25 PM, Dain Sundstrom wrote:
> On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
>
>> I'm not sure that we will ever agree with each other. I'm not
>> even trying to convince you or anyone else... cause at this point
>> I simply don't care.
>
> Before we continue this discussion, how about we first determine if
> anyone cares?
>
> If you care about how the specs use one version for all specs or
> one version for each spec, please respond to this email.
>
> -dain
>
Matt Hogstrom
matt@hogstrom.org
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Sweet
On Dec 13, 2006, at 2:02 PM, Dain Sundstrom wrote:
> I talked to Kevan off line and he is totally cool with doing one
> version per spec.
>
> I'm going to spin up binaries to start a release vote today. This
> way we can put together the 1.2-beta and 2.0-M1 binaries for voting
> later this week :)
>
> -dain
>
Matt Hogstrom
matt@hogstrom.org
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Dain Sundstrom <da...@iq80.com>.
I talked to Kevan off line and he is totally cool with doing one
version per spec.
I'm going to spin up binaries to start a release vote today. This
way we can put together the 1.2-beta and 2.0-M1 binaries for voting
later this week :)
-dain
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by David Blevins <da...@visi.com>.
On Dec 12, 2006, at 10:09 AM, Donald Woods wrote:
> Hmmm.... sounds like a good approach - only have the specs in trunk
> or a branch that are undergoing changes and all the others live in
> tags until changes are needed.
> That would make it easier for anyone trying to find the latest
> specs not to get confused with all of them being in trunk, but only
> one or two of them being published....
> That would make builds easier too, since running mvn under the
> specs directory would only be building the few specs that are there
> and they would each have their own version number.
I like that approach. Posted the same idea in October when we had
this discussion.
On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
> Was more saying "let's just delete these specs from trunk" or
> otherwise get rid of them and leave only the specs that change
> [....] The code is tagged, so it's safe. Perhaps the issue is
> that we don't need these unchanging modules in trunk in the first
> place.
I still like the idea.
-David
>
> Jason Dillon wrote:
>> On Dec 11, 2006, at 8:23 PM, David Blevins wrote:
>>> Just to quietly raise my hand, we used to do option 2 on 1.0-M1
>>> through 1.0-M5 and I was release manager nearly all of those. I
>>> advocated using one version for all specs. I eventually grew to
>>> dislike that (http://marc.theaimsgroup.com/?l=geronimo-
>>> dev&m=113857091823325&w=2).
>>>
>>> I understand institutional memory is short if people really want
>>> to do the one version thing again, that's cool. I just want to
>>> go on record as saying I think the way we've attempted the one
>>> version for each approach also turned out to be flawed. We
>>> should have marked all the dependencies of each spec with
>>> '<scope>provided' shutting off maven's transitivity which would
>>> fix every issue I'm aware of with managing relationships between
>>> specs.
>> Thought I think it is odd, to *move* code from a branch to a tag,
>> and then back to a branch, this might be a better solution for
>> these specs that will never change, or change like every 5 years
>> er something.
>> Or maybe... the problem is really to tool we are using, or the way
>> we are using that tool. Perhaps if mvn could handle building a
>> release of a set of modules in one step and each of theses modules
>> had its own trunk/tags/branches then none of this will matter?
>> --jason
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Donald Woods <dr...@yahoo.com>.
Hmmm.... sounds like a good approach - only have the specs in trunk or a
branch that are undergoing changes and all the others live in tags until
changes are needed.
That would make it easier for anyone trying to find the latest specs not
to get confused with all of them being in trunk, but only one or two of
them being published....
That would make builds easier too, since running mvn under the specs
directory would only be building the few specs that are there and they
would each have their own version number.
-Donald
Jason Dillon wrote:
> On Dec 11, 2006, at 8:23 PM, David Blevins wrote:
>> Just to quietly raise my hand, we used to do option 2 on 1.0-M1
>> through 1.0-M5 and I was release manager nearly all of those. I
>> advocated using one version for all specs. I eventually grew to
>> dislike that
>> (http://marc.theaimsgroup.com/?l=geronimo-dev&m=113857091823325&w=2).
>>
>> I understand institutional memory is short if people really want to do
>> the one version thing again, that's cool. I just want to go on record
>> as saying I think the way we've attempted the one version for each
>> approach also turned out to be flawed. We should have marked all the
>> dependencies of each spec with '<scope>provided' shutting off maven's
>> transitivity which would fix every issue I'm aware of with managing
>> relationships between specs.
>
> Thought I think it is odd, to *move* code from a branch to a tag, and
> then back to a branch, this might be a better solution for these specs
> that will never change, or change like every 5 years er something.
>
> Or maybe... the problem is really to tool we are using, or the way we
> are using that tool. Perhaps if mvn could handle building a release of
> a set of modules in one step and each of theses modules had its own
> trunk/tags/branches then none of this will matter?
>
> --jason
>
>
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 8:23 PM, David Blevins wrote:
> Just to quietly raise my hand, we used to do option 2 on 1.0-M1
> through 1.0-M5 and I was release manager nearly all of those. I
> advocated using one version for all specs. I eventually grew to
> dislike that (http://marc.theaimsgroup.com/?l=geronimo-
> dev&m=113857091823325&w=2).
>
> I understand institutional memory is short if people really want to
> do the one version thing again, that's cool. I just want to go on
> record as saying I think the way we've attempted the one version
> for each approach also turned out to be flawed. We should have
> marked all the dependencies of each spec with '<scope>provided'
> shutting off maven's transitivity which would fix every issue I'm
> aware of with managing relationships between specs.
Thought I think it is odd, to *move* code from a branch to a tag, and
then back to a branch, this might be a better solution for these
specs that will never change, or change like every 5 years er something.
Or maybe... the problem is really to tool we are using, or the way we
are using that tool. Perhaps if mvn could handle building a release
of a set of modules in one step and each of theses modules had its
own trunk/tags/branches then none of this will matter?
--jason
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by David Blevins <da...@visi.com>.
On Dec 11, 2006, at 7:36 PM, Matt Hogstrom wrote:
> Ok, I still don't have the brain power but this is in the back of
> my mind.
>
> Here is my take (yes, I'm rehashing stuff).
>
> Currently what we have we don't want so we can eliminate the option
> where we release everything under an uber version number that has
> no bearing on the actual artifacts being released. So, for
> instance, when we released a modified version of JAAC its version
> number was 1.1.1 and all the other modules in the branches/1.1 were
> at 1.0, 1.0.1 and 1.1 which is horribly confusing.
>
> We're left with other alternatives of which two seem to be the
> current topic of discussion.
>
> Option 1:
> Version all modules independently with no association to each other
> except through perhaps dependencies.
> - Makes releasing hard as coordinating multiple modules is the
> responsibility of the consumer
> - Makes releasing easy as there is almost no interdependence so
> work on different modules can proceed at their own pace.
>
> Option 2:
> Version all modules together under a single version number. This
> means if we changed JAAC in the above example all other modules
> would also be released as -1.1.1 even though they didn't changed.
> - This makes releasing easy as all modules get pushed out a once.
> - This makes releasing hard as one module that is having trouble or
> people don't have time to work on it holds up the whole train.
>
> The factor that I think impacts the above options the most is the
> amount of churn in the specs. A lot of churn makes interdependence
> a PITA and makes option 1 favorable and a little churn makes option
> 2 more favorable.
>
> Since specs are versioned / maintained infrequently, we hate the
> existing system and we need to get past the debate and get
> something done *I suggest that we adopt option 2*, give it a go,
> and if it sucks wind then we move to version 3.0 and switch to
> option 1.
Just to quietly raise my hand, we used to do option 2 on 1.0-M1
through 1.0-M5 and I was release manager nearly all of those. I
advocated using one version for all specs. I eventually grew to
dislike that (http://marc.theaimsgroup.com/?l=geronimo-
dev&m=113857091823325&w=2).
I understand institutional memory is short if people really want to
do the one version thing again, that's cool. I just want to go on
record as saying I think the way we've attempted the one version for
each approach also turned out to be flawed. We should have marked
all the dependencies of each spec with '<scope>provided' shutting off
maven's transitivity which would fix every issue I'm aware of with
managing relationships between specs.
Thanks,
David
>
> Either way people will be unhappy but getting past this roadblock
> is important.
>
> Is anyone -1 on this approach?
>
> On Dec 11, 2006, at 9:25 PM, Dain Sundstrom wrote:
>
>> On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
>>
>>> I'm not sure that we will ever agree with each other. I'm not
>>> even trying to convince you or anyone else... cause at this point
>>> I simply don't care.
>>
>> Before we continue this discussion, how about we first determine
>> if anyone cares?
>>
>> If you care about how the specs use one version for all specs or
>> one version for each spec, please respond to this email.
>>
>> -dain
>>
>
> Matt Hogstrom
> matt@hogstrom.org
>
>
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 7:36 PM, Matt Hogstrom wrote:
> Option 1:
> Version all modules independently with no association to each other
> except through perhaps dependencies.
> - Makes releasing hard as coordinating multiple modules is the
> responsibility of the consumer
> - Makes releasing easy as there is almost no interdependence so
> work on different modules can proceed at their own pace.
>
> Option 2:
> Version all modules together under a single version number. This
> means if we changed JAAC in the above example all other modules
> would also be released as -1.1.1 even though they didn't changed.
> - This makes releasing easy as all modules get pushed out a once.
> - This makes releasing hard as one module that is having trouble or
> people don't have time to work on it holds up the whole train.
I'm not sure that either of these options really covers each side of
the issues completely. I think one of the big ones, is from the
consumers side of these artifacts, how many version numbers does one
need to know about to find out what the latest version of each spec
is? Maybe these silly examples might help explain my thinking (or
not)...
I'm Joe Java Developer and I just want the latest and greatest and
don't care about any of the other details. Do I need to know about
~30 versions or one version? Joe's little brother Jimmy is also
learning about all of this too, and he might not know which versions
of specs, versioned independently, are intended to be used together,
and if he picks the wrong versions of some specs that have deps on
other specs which he uses, then his project will end up with multiple
versions of the same specs in his project.
Or lets say I'm Bob Build Master, and I don't know all of the details
about the spec dependencies, I am just responsible for making
releases... do I want to have to manage ~30 projects, releasing them
in the right order when something changes, or do I want one project?
The release build may be frequent or infrequent, Bob doesn't really
care... but he's dealing with so many other builds that its probably
best for him not to really need to worry about it.
Sammy ServletEngine Developer might only care about that JSP or
Servlet specs and specifically only care about when the code changes,
or if Sammy's team was using Maven 2, then he would also care when
the pom's were changed, and in that case they would need to pay
attention to what was actually being released (ie. the release notes)
for specs in either model.
I believe in Joe's, Jimmy's and Bob's case that one version is the
obvious choice. For Sammy, per-module versions may make a little
more sense, though the stretch to using one version may actually be
easier for them to manage, especially if they just want to use the
specs with the latest code and pom changes... otherwise they might
pay more attention to what was actually in the release, and thus one
version or multiple versions would effectively be the same amount of
work for them making it effectively the same.
* * *
Anyways, when it comes down to it... I'm just trying to give some
advise on how I recommend Geronimo setup and maintain its growing
number of projects (and growing number of modules).
Its not "my way or the highway", but more that I think you might want
to travel on the same road to avoid bumps in the future... and I hope
that if you choose not to that Its not too painful to fix the flat
when it occurs.
--jason
Re: Who cares? [was: [DISCUSS] specs versioning]
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Ok, I still don't have the brain power but this is in the back of my
mind.
Here is my take (yes, I'm rehashing stuff).
Currently what we have we don't want so we can eliminate the option
where we release everything under an uber version number that has no
bearing on the actual artifacts being released. So, for instance,
when we released a modified version of JAAC its version number was
1.1.1 and all the other modules in the branches/1.1 were at 1.0,
1.0.1 and 1.1 which is horribly confusing.
We're left with other alternatives of which two seem to be the
current topic of discussion.
Option 1:
Version all modules independently with no association to each other
except through perhaps dependencies.
- Makes releasing hard as coordinating multiple modules is the
responsibility of the consumer
- Makes releasing easy as there is almost no interdependence so work
on different modules can proceed at their own pace.
Option 2:
Version all modules together under a single version number. This
means if we changed JAAC in the above example all other modules would
also be released as -1.1.1 even though they didn't changed.
- This makes releasing easy as all modules get pushed out a once.
- This makes releasing hard as one module that is having trouble or
people don't have time to work on it holds up the whole train.
The factor that I think impacts the above options the most is the
amount of churn in the specs. A lot of churn makes interdependence a
PITA and makes option 1 favorable and a little churn makes option 2
more favorable.
Since specs are versioned / maintained infrequently, we hate the
existing system and we need to get past the debate and get something
done *I suggest that we adopt option 2*, give it a go, and if it
sucks wind then we move to version 3.0 and switch to option 1.
Either way people will be unhappy but getting past this roadblock is
important.
Is anyone -1 on this approach?
On Dec 11, 2006, at 9:25 PM, Dain Sundstrom wrote:
> On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
>
>> I'm not sure that we will ever agree with each other. I'm not
>> even trying to convince you or anyone else... cause at this point
>> I simply don't care.
>
> Before we continue this discussion, how about we first determine if
> anyone cares?
>
> If you care about how the specs use one version for all specs or
> one version for each spec, please respond to this email.
>
> -dain
>
Matt Hogstrom
matt@hogstrom.org
Who cares? [was: [DISCUSS] specs versioning]
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 5:59 PM, Jason Dillon wrote:
> I'm not sure that we will ever agree with each other. I'm not even
> trying to convince you or anyone else... cause at this point I
> simply don't care.
Before we continue this discussion, how about we first determine if
anyone cares?
If you care about how the specs use one version for all specs or one
version for each spec, please respond to this email.
-dain
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 5:39 PM, Dain Sundstrom wrote:
>> In several cases, you must release more than one spec at a time.
>> But my point was more general... as in general its easier to
>> manage releases for a set of modules together instead of one by one.
>
> You are assuming that is makes since to release a set of specs at
> once. Normally only one spec changes at a time (due to a bug),
> then there is no reason to create a big set of every single spec
> jar we have ever created just to release a single jar.
If that spec has not dependencies on other specs, sure... but there
are some which are dependent, and in those cases you must handle them
too... and I am telling you now that people will miss them and screw
up the release, cause a bunch more work, and IMO a lot more confusion
or even build related issues if the fixed release is the same version.
>>>> Also, if you consider hooking up this process to a build
>>>> automation tool, so that each build gets released by that tool,
>>>> then the specs project effectively needs to get split up into a
>>>> project per-module, which is a bunch of unneeded overhead.
>>>
>>> Only the specs being worked on would need build automation, and
>>> event then I would suggest G never uses SNAPSHOT specs. Instead
>>> when the specs are mostly complete we release a M1 and when they
>>> are finished we release 1.0. In that case no automation is
>>> necessary.
>>
>> It is still much easier to just setup one project for all of the
>> specs rather than add/remove projects as needed.
>>
>> * * *
>>
>> If you folks really want to version spec modules independently,
>> then I suggest you also consider versioning server modules
>> independently.
>>
>> I certainly don't recommend doing either, but IMO they are both
>> the same problem from a build perspective, just with slightly
>> different context.
>
> I think you are using a lame rhetoric technique to make your
> point. You are saying if you want to do X, then you should
> certainly do Y, and since no one would ever want to do Y, then we
> should never do X.
Fine, whatever dude... I was using a lame technique you used earlier
in this thread playing devils advocate.
> Things that are independently useable and move independently should
> be versioned independently. The specs are both in this case.
Its not worth the overhead.
* * *
I'm not sure that we will ever agree with each other. I'm not even
trying to convince you or anyone else... cause at this point I simply
don't care. I commented only because I believed your statements were
a little overly simplified and misleading in the larger, longer term
picture.
But, what do I know... I've been wrong before.
I'm sick and tired of this argument though, so just pick something
and do it.
--jason
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 2:08 PM, Jason Dillon wrote:
> On Dec 11, 2006, at 1:53 PM, Dain Sundstrom wrote:
>>>> Um.. that's not true. Maven has full support for this. Also it
>>>> doesn't make the release manager's job harder.
>>>
>>> Sure it does Dain, running one set of `mvn release:prepare && mvn
>>> release:perform` vs, running one per spec module. That is
>>> significantly more work for the latter.
>>
>> You are implying that we tend to release gobs of specs at one.
>> The reality is specs rarely change and when we do find a problem
>> it is with one module not everything.
>
> In several cases, you must release more than one spec at a time.
> But my point was more general... as in general its easier to manage
> releases for a set of modules together instead of one by one.
You are assuming that is makes since to release a set of specs at
once. Normally only one spec changes at a time (due to a bug), then
there is no reason to create a big set of every single spec jar we
have ever created just to release a single jar.
>>> Also, if you consider hooking up this process to a build
>>> automation tool, so that each build gets released by that tool,
>>> then the specs project effectively needs to get split up into a
>>> project per-module, which is a bunch of unneeded overhead.
>>
>> Only the specs being worked on would need build automation, and
>> event then I would suggest G never uses SNAPSHOT specs. Instead
>> when the specs are mostly complete we release a M1 and when they
>> are finished we release 1.0. In that case no automation is
>> necessary.
>
> It is still much easier to just setup one project for all of the
> specs rather than add/remove projects as needed.
>
> * * *
>
> If you folks really want to version spec modules independently,
> then I suggest you also consider versioning server modules
> independently.
>
> I certainly don't recommend doing either, but IMO they are both the
> same problem from a build perspective, just with slightly different
> context.
I think you are using a lame rhetoric technique to make your point.
You are saying if you want to do X, then you should certainly do Y,
and since no one would ever want to do Y, then we should never do X.
Things that are independently useable and move independently should
be versioned independently. The specs are both in this case.
-dain
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 1:53 PM, Dain Sundstrom wrote:
>>> Um.. that's not true. Maven has full support for this. Also it
>>> doesn't make the release manager's job harder.
>>
>> Sure it does Dain, running one set of `mvn release:prepare && mvn
>> release:perform` vs, running one per spec module. That is
>> significantly more work for the latter.
>
> You are implying that we tend to release gobs of specs at one. The
> reality is specs rarely change and when we do find a problem it is
> with one module not everything.
In several cases, you must release more than one spec at a time. But
my point was more general... as in general its easier to manage
releases for a set of modules together instead of one by one.
>> Also, if you consider hooking up this process to a build
>> automation tool, so that each build gets released by that tool,
>> then the specs project effectively needs to get split up into a
>> project per-module, which is a bunch of unneeded overhead.
>
> Only the specs being worked on would need build automation, and
> event then I would suggest G never uses SNAPSHOT specs. Instead
> when the specs are mostly complete we release a M1 and when they
> are finished we release 1.0. In that case no automation is necessary.
It is still much easier to just setup one project for all of the
specs rather than add/remove projects as needed.
* * *
If you folks really want to version spec modules independently, then
I suggest you also consider versioning server modules independently.
I certainly don't recommend doing either, but IMO they are both the
same problem from a build perspective, just with slightly different
context.
--jason
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 1:41 PM, Jason Dillon wrote:
> On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
>> On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
>>
>>> I'm in favor of a single version for all specs. Versioning the
>>> specs
>>> individually has some advantages but makes the release manager's job
>>> more difficult since the tooling doesn't readily support that
>>> approach.
>>
>> Um.. that's not true. Maven has full support for this. Also it
>> doesn't make the release manager's job harder.
>
> Sure it does Dain, running one set of `mvn release:prepare && mvn
> release:perform` vs, running one per spec module. That is
> significantly more work for the latter.
You are implying that we tend to release gobs of specs at one. The
reality is specs rarely change and when we do find a problem it is
with one module not everything.
> Also, if you consider hooking up this process to a build automation
> tool, so that each build gets released by that tool, then the specs
> project effectively needs to get split up into a project per-
> module, which is a bunch of unneeded overhead.
Only the specs being worked on would need build automation, and event
then I would suggest G never uses SNAPSHOT specs. Instead when the
specs are mostly complete we release a M1 and when they are finished
we release 1.0. In that case no automation is necessary.
-dain
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 12:16 PM, Dain Sundstrom wrote:
> On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
>
>> I'm in favor of a single version for all specs. Versioning the specs
>> individually has some advantages but makes the release manager's job
>> more difficult since the tooling doesn't readily support that
>> approach.
>
> Um.. that's not true. Maven has full support for this. Also it
> doesn't make the release manager's job harder.
Sure it does Dain, running one set of `mvn release:prepare && mvn
release:perform` vs, running one per spec module. That is
significantly more work for the latter. Also, if you consider
hooking up this process to a build automation tool, so that each
build gets released by that tool, then the specs project effectively
needs to get split up into a project per-module, which is a bunch of
unneeded overhead.
While mvn can go both ways, one version for many modules is
significantly easier.
>> And as a developer (at least for me) a single version is
>> more intuitive, evidenced by my recent snafu where I created the
>> initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason
>> keeps a very close eye on things and suggested using 1.0-SNAPSHOT
>> instead.
>
> Um I think that goes both ways. Because all specs are currently at
> 1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT.
> As specs become more independent, I would expect you would
> naturally choose 1.0-SNAPSHOT for a new spec. In addition, new
> specs do not come along that often so making a mistake once a year
> is not a big deal.
Could be, though the error was because it was a svn copy, not because
someone though that it should start at a different version. So the
exact same problem could happen either way. The only way to remove
that completely is to remove the version from the equation... one
version for all specs does just that.
--jason
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 10:52 AM, Paul McMahan wrote:
> I'm in favor of a single version for all specs. Versioning the specs
> individually has some advantages but makes the release manager's job
> more difficult since the tooling doesn't readily support that
> approach.
Um.. that's not true. Maven has full support for this. Also it
doesn't make the release manager's job harder.
> And as a developer (at least for me) a single version is
> more intuitive, evidenced by my recent snafu where I created the
> initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason
> keeps a very close eye on things and suggested using 1.0-SNAPSHOT
> instead.
Um I think that goes both ways. Because all specs are currently at
1.1-SNAPSHOT, you mistakenly created a new spec at 1.1-SNAPSHOT. As
specs become more independent, I would expect you would naturally
choose 1.0-SNAPSHOT for a new spec. In addition, new specs do not
come along that often so making a mistake once a year is not a big deal.
> I also believe having the specs all at a single release is consistent
> with the approach we use in server/trunk, where the artifacts share
> the same geronimo version and when necessary a version number can be
> included in the artifactId. Consistency has its benefits.
In that case, why not move specs into the server tree?
-dain
Re: [DISCUSS] specs versioning
Posted by Paul McMahan <pa...@gmail.com>.
I'm in favor of a single version for all specs. Versioning the specs
individually has some advantages but makes the release manager's job
more difficult since the tooling doesn't readily support that
approach. And as a developer (at least for me) a single version is
more intuitive, evidenced by my recent snafu where I created the
initial version of jsp 2.1 spec at 1.1-SNAPSHOT. Thankfully Jason
keeps a very close eye on things and suggested using 1.0-SNAPSHOT
instead.
I also believe having the specs all at a single release is consistent
with the approach we use in server/trunk, where the artifacts share
the same geronimo version and when necessary a version number can be
included in the artifactId. Consistency has its benefits.
Best wishes,
Paul
On 12/11/06, Kevan Miller <ke...@gmail.com> wrote:
> The versioning policy for our geronimo specs has been floating around
> for a while now. I'd like to see this issue resolved.
>
> There have been two approaches discussed
>
> 1) Single version -- all specs are released under the same version
> number.
> 2) Separate version -- each spec is versioned separately from the
> other specs.
>
> Dain created a review of the two proposals in the wiki -- http://
> cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think
> you can quibble over a few of the details, but it does a good job at
> summarizing the issue.
>
> IMO, there are going to be drawbacks no matter which approach we
> take. However, I'm going to be happy with either approach as long as
> we reach a *decision*. I'd prefer that we reach consensus on this
> discussion thread. However, if necessary, we can vote on the issue.
>
> Personally, I think we should use a single version for releasing our
> specs. I think this makes it easier for us as developers in managing
> spec releases. I think users will find it easier to collect a
> consistent set of specifications. I think these benefits outweigh
> concerns over the lack of flexibility and the wasteful aspects of re-
> releasing unchanged specifications.
>
> I suppose there's a hybrid option where we release separate versions,
> now, and move to a single version policy (2.0?) for our next release.
>
> --kevan
>
>
>
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 10:13 AM, Kevan Miller wrote:
> Personally, I think we should use a single version for releasing
> our specs. I think this makes it easier for us as developers in
> managing spec releases. I think users will find it easier to
> collect a consistent set of specifications. I think these benefits
> outweigh concerns over the lack of flexibility and the wasteful
> aspects of re-releasing unchanged specifications.
I'm obviously +1 on this. One version provides much needed
simplification for the build process. IMO maven's existing model of
versioning each module separately is a dangerous build anti-pattern
and we should not follow it.
> I suppose there's a hybrid option where we release separate
> versions, now, and move to a single version policy (2.0?) for our
> next release.
Ya, thats probably what I would recommend... though really, if we can
agree to use one version then we could just a 2.0 now and update G
1.2 and 2.0 to just use those versions.
--jason
Re: [DISCUSS] specs versioning
Posted by Jason Dillon <ja...@planet57.com>.
On Dec 11, 2006, at 1:13 PM, Matt Hogstrom wrote:
> IMHO I like option 3 which is both option 1 and 2. First, I think
> all SPECs should be versioned independently as not everyone is
> interested in all the specs. If, for instance, the Tomcat dudes
> decide to pick up anything we have they would only be interested in
> a subset and shouldn't be forced to consume the whole Java EE banana.
>
> So, in that light I think they should all be versioned separately.
> We should probably have a separate uber spec project that pulls in
> a set of versioned specs and releases them as a set so that people
> that want the whole enchilada can get them. The uber approach
> would only be compiling a set of released specs (which were
> released separately.
>
> For this proposal...I'd say release them individually and make the
> uber spec as the next step. IMHO small largely immutable specs
> make sense to me.
Uber specs are another anti-pattern, and I do not recommend that we
bring them back. If you are using a specific spec in your app, then
you really should not need to (or want to) pull in every other spec
that is part of that release... doing so is very sloppy IMO.
I don't recommend we create or use anything like an uber-spec anywhere.
--jason
Re: [DISCUSS] specs versioning
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 11, 2006, at 1:13 PM, Matt Hogstrom wrote:
> IMHO I like option 3 which is both option 1 and 2. First, I think
> all SPECs should be versioned independently as not everyone is
> interested in all the specs. If, for instance, the Tomcat dudes
> decide to pick up anything we have they would only be interested in
> a subset and shouldn't be forced to consume the whole Java EE banana.
>
> So, in that light I think they should all be versioned separately.
> We should probably have a separate uber spec project that pulls in
> a set of versioned specs and releases them as a set so that people
> that want the whole enchilada can get them. The uber approach
> would only be compiling a set of released specs (which were
> released separately.
That sounds interesting, but I think we should wait until someone
asks for that feature. I personally have found that in most cases
you end up using only a couple of specs at a time. If someone has a
good use case for an uber bundle, then we pull it together uber jar
(or uber pom for maven users).
-dain
Re: [DISCUSS] specs versioning
Posted by Matt Hogstrom <ma...@hogstrom.org>.
IMHO I like option 3 which is both option 1 and 2. First, I think
all SPECs should be versioned independently as not everyone is
interested in all the specs. If, for instance, the Tomcat dudes
decide to pick up anything we have they would only be interested in a
subset and shouldn't be forced to consume the whole Java EE banana.
So, in that light I think they should all be versioned separately.
We should probably have a separate uber spec project that pulls in a
set of versioned specs and releases them as a set so that people that
want the whole enchilada can get them. The uber approach would only
be compiling a set of released specs (which were released separately.
For this proposal...I'd say release them individually and make the
uber spec as the next step. IMHO small largely immutable specs make
sense to me.
On Dec 11, 2006, at 1:13 PM, Kevan Miller wrote:
> The versioning policy for our geronimo specs has been floating
> around for a while now. I'd like to see this issue resolved.
>
> There have been two approaches discussed
>
> 1) Single version -- all specs are released under the same version
> number.
> 2) Separate version -- each spec is versioned separately from the
> other specs.
>
> Dain created a review of the two proposals in the wiki -- http://
> cwiki.apache.org/confluence/display/GMOxDEV/Spec+Versioning I think
> you can quibble over a few of the details, but it does a good job
> at summarizing the issue.
>
> IMO, there are going to be drawbacks no matter which approach we
> take. However, I'm going to be happy with either approach as long
> as we reach a *decision*. I'd prefer that we reach consensus on
> this discussion thread. However, if necessary, we can vote on the
> issue.
>
> Personally, I think we should use a single version for releasing
> our specs. I think this makes it easier for us as developers in
> managing spec releases. I think users will find it easier to
> collect a consistent set of specifications. I think these benefits
> outweigh concerns over the lack of flexibility and the wasteful
> aspects of re-releasing unchanged specifications.
>
> I suppose there's a hybrid option where we release separate
> versions, now, and move to a single version policy (2.0?) for our
> next release.
>
> --kevan
>
>
>
Matt Hogstrom
matt@hogstrom.org
Re: [DISCUSS] specs versioning
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Wow...your doing better than me...I'd probably have replied
forgetting I sent the original :)
On Dec 13, 2006, at 7:22 PM, Kevan Miller wrote:
> Heh. That's pretty bad... Tried to send the following note, twice.
> Both times addressed to myself rather that dev@... :-(
>
> Third time's the charm?
>
> --kevan
>
> On Dec 13, 2006, at 7:34 AM, Kevan Miller wrote:
>
>> Ooops. I sent the following, yesterday. However, "Reply" addressed
>> the response directly to me, rather than dev@
>>
>> OK. Sounds like the latest thinking is that specs/trunk will only
>> contain specs that are actively being developed. Once a spec is
>> released and tagged, it is removed from trunk.
>>
>> I'm good with that approach.
>>
>> The only issue I see is that poor soul who insists on building our
>> specs from source. They'll need to sort out the appropriate spec
>> versions from specs/tags and build each individual spec. Not too
>> many who'd want to do that, but it's an inconvenience to pull them
>> together...
You are right...if we are infused with a rush of people wanting to
develop specs then we should certainly change our policy and we can.
For now I'm happy the train is moving :)
>>
>> I think we can start making this happen.
>>
>> --kevan
>>
>
>
Matt Hogstrom
matt@hogstrom.org
Re: [DISCUSS] specs versioning
Posted by Kevan Miller <ke...@gmail.com>.
Heh. That's pretty bad... Tried to send the following note, twice.
Both times addressed to myself rather that dev@... :-(
Third time's the charm?
--kevan
On Dec 13, 2006, at 7:34 AM, Kevan Miller wrote:
> Ooops. I sent the following, yesterday. However, "Reply" addressed
> the response directly to me, rather than dev@
>
> OK. Sounds like the latest thinking is that specs/trunk will only
> contain specs that are actively being developed. Once a spec is
> released and tagged, it is removed from trunk.
>
> I'm good with that approach.
>
> The only issue I see is that poor soul who insists on building our
> specs from source. They'll need to sort out the appropriate spec
> versions from specs/tags and build each individual spec. Not too
> many who'd want to do that, but it's an inconvenience to pull them
> together...
>
> I think we can start making this happen.
>
> --kevan
>