Yes this is very similar to the version scheme we've used. Basically I've also been thinking that the apache version would be a 4.0.0, since the package naming makes everything incompatible. My question in this regard was that if we're anyways doing that right now, we might as well ensure we dont want to switch to 5.0.0 too soon because we did not take the chance to make other API improvements.
2013/6/28 Noah Slater <[email protected]> > What versioning scheme do you use? Have you seen http://semver.org/before? > > If we used semver, the org.apache change would be a major release bump. > > > On 27 June 2013 19:58, Henry Saputra <[email protected]> wrote: > > > I would say baby steps for the changes. > > > > Changing package names to org.apache.metamodel will already do damages to > > clients using MetaModel or develop extension. > > > > For first release I am proposing we just make solid MetModel release > > following Apache naming and other small enhancements and bug fixes. > > > > We could move fast in terms of releases, so next one within a month of > the > > first release maybe we could introduce API changes. > > > > Just my 2 cents > > > > - Henry > > > > On Thu, Jun 27, 2013 at 11:24 AM, Kasper Sørensen < > > [email protected]> wrote: > > > > > Hi all, > > > > > > When we're moving the code base to Apache, some major breaking changes > > will > > > take place to the codebase. For one, every package will change from > org.* > > > eobjects*.metamodel... to org.*apache*.metamodel... > > > > > > So in my opinion, no matter how we gentle we make the migration, it > will > > > break backwards compatibility and Apache MetaModel will not be a > drop-in > > > replacement for the old MetaModel. > > > > > > This open up a devilish question: When we're anyways breaking backwards > > > compatibility, are there things we would want to change in MetaModel's > > > remaining interface in the same go? Or should we try to control the > > changes > > > a bit - making it still quite effortless to migrate, if you're willing > to > > > do a search/replace on the package names? > > > > > > To give an example, I have a small topic on my mind that I would like > to > > > change, but it's never been important enough for me to want to break > > > compatibility over it: > > > > > > The interfaces for Schema, Table and Column expose arrays instead of > > > > collections/lists (for instance Schema.getTables()). But in hindsight > > it > > > > would have been better to go for a collection type (List probably) to > > > make > > > > it possible to expose a truly immutable schema model. Also, since > List > > is > > > > an interface, it's easier to mock if needed. > > > > > > > > > If we feel that the time is right for such API refactorings, we should > > > probably try now to compile a list of wishes for API changes that we > > could > > > introduce? > > > > > > What do you think? Is it best to make the smoothest possible migration, > > or > > > is now a good time to also show courage to make API changes? > > > > > > Best regards, > > > Kasper > > > > > > > > > -- > NS >
