Wanted to add a datapoint that it is OK to keep the old package names and interfaces as long as they are deprecated explicitly. I did a similar exercise for Apache Sqoop and documented the way to go about it on the wiki [1].
This will be helpful if you would like to provide a smooth transition to your existing community and also continue to work with any third-party systems that may be using your APIs. If these are not major concerns for the project, then perhaps it is best to do a clean cut-over and break compatibility. [1] https://cwiki.apache.org/confluence/display/SQOOP/Transition+from+Cloudera Regards, Arvind Prabhakar On Sat, Jun 29, 2013 at 8:41 AM, Kasper Sørensen < [email protected]> wrote: > 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 > > >
