On 11/3/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > > What about this. > > Struts 1.3.0 Distro > - struts-core-1.3.0 > - struts-taglib-1.3.0 > - struts-tiles-1.3.0 > - struts-el-1.3.0 > - struts-apps-1.3.0 > - struts-site-1.3.0 > - struts-extras-1.3.0 > > Subprojects can have their own independent release numbers all being > 1.3.0.x, with the "1.3.0" dictated by struts-core. > Once we release struts-core-1.3.1, the other subprojects jump to 1.3.1. > This way it's always clear which distro a none-core subproject release > works with. > (i.e. you can't be sure about using taglib-1.3.1.2 with core-1.3.0, > but you're sure that taglib-1.3.0.4 will work)
I started going down this line of thinking too, but there's a flaw. I believe that we need to allow for each and every piece to increase the major version number when necessary. For example, say we had a complete revamp of one add-on, including API changes, but it still works just fine with struts-core-1.3.0. IMO, that calls for a major version increment for the add-on, and I don't like the idea of forcing it to remain stuck under the 1.3.0.x line of numbering for artificial reasons. I believe the simplest way to handle this, and the one that will make the most sense to our user base, is to number the bundled distributions after the struts-core component, and let the version numbers of add-ons do what they will. I think it's highly unlikely that we'll want to rev the bundled distribution without a rev of struts-core, since people can download updated add-ons without having to grab the entire bundle, so I don't foresee issues there. (And if we _do_ end up doing that for some reason, we can go to the 4-part numbering for the bundles.) -- Martin Cooper Subprojects that get added to the main distro assume the same versioning > rules. > Come to think of it, we could start BSF and scripting as > 1.2.7.0<http://1.2.7.0>if > they depend on 1.2.7. This way they'd start off with the same rules > already, and everyone'll know you can use them with 1.2.7. > > In any case, I'm glad we're getting rid of "Classic". > > Hubert > > > On 11/3/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 11/2/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > > I started to do that, but the idea was to also include the new > > > subprojects, like Scripting and Flow and Faces, which would start at a > > > 1.0.0 release. It seemed consistant to start with 1.0.0. > > > > I missed the decision to include BSF, Flow and Faces. I don't think > > they belong in this distribution-- they have declared dependencies on > > Struts 1.2.7 and prior. > > > > But I still think I'm working on Struts 1.3, so see below. :) > > > > > And, it's *VERY* important that people realize that Struts Core > > > LIbrary is *not* a product, it's a distribution of products, like a > > > Linux distribution. That was already becoming a problem with the > > > Struts Classic moniker. > > > > After five years, the concept of Struts as a product is not going to > > go away so easily. > > > > Whether we call it 'Classic' or 'Core Library' or something else, I > > really think it needs to have 1.3 in the name and contain the 1.3.x > > versions of the sub-projects that make up what people think of as > > "Struts" (plus any new additions that come along.) > > > > What about versioning as 1.3_01 and just sequentially number them as > > 'builds' of Struts Core Library 1.3? As Craig mentioned, we're > > stating that this particular combination of sub-project versions is > > known to work together. > > > > -- > > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
