You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/12/12 03:25:30 UTC
Who cares? [was: [DISCUSS] specs versioning]
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: 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