Yes, the configuration2-packaged classes should be part of the 2.x release series.
On 12/18/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: > >> So I will probably follow this road. This is a good opportunity for a > >> refactoring and polishing of some interfaces and base > >> classes. Because > >> we will have major changes, changing the package name (maybe to > >> o.a.c.configuration2?) will certainly make sense. > > > > I'd go for o.a.c.configuration2 here. > > same here > > >> It would be good however to handle this commons-wide in a > >> consistent way. > > > > The question is: Should we start again with 1.0 for such a > > component or do we align the number in the package with the major > > number if we expect a completely incompatible package? > > > > Example for a version histories: > > > > - with aligned major number: > > > > o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 > > o.a.c.configuration2: 2.0, 2.1, 3.0, 3.1, 3.2, 4.0 > > o.a.c.configuration5: 5.0, 5.1 > > IMO the above is more straight forward than the following... > > > - with resetted number: > > > > o.a.c.configuration: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 > > o.a.c.configuration2: 1.0, 1.1, 2.0, 2.1, 2.2, 3.0 > > o.a.c.configuration3: 1.0, 1.1 > > cheers > -- > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
