Re: [DISCUSS] specs versioning
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 [EMAIL PROTECTED] :-( 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 [EMAIL PROTECTED]
Re: [DISCUSS] specs versioning
Heh. That's pretty bad... Tried to send the following note, twice. Both times addressed to myself rather that [EMAIL PROTECTED] :-( 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
Re: [DISCUSS] specs versioning
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
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
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
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
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
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
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
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
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
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
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
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 [EMAIL PROTECTED]
Re: [DISCUSS] specs versioning
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote: On 12/11/06, Dain Sundstrom <[EMAIL PROTECTED]> 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 '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
On Dec 11, 2006, at 12:40 PM, Paul McMahan wrote: On 12/11/06, Dain Sundstrom <[EMAIL PROTECTED]> 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
On 12/11/06, Dain Sundstrom <[EMAIL PROTECTED]> 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: [DISCUSS] specs versioning
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
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 <[EMAIL PROTECTED]> 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
