If you have other breaking changes you can get in soon, I'd recommend doing them all at once. Best not to have a succession of backwards incompatible releases.
The process for the release is that you make a release candidate and upload it to your personal space, and call a vote. But we must not call these releases until they have been voted on by the community. (To the same end, nightly builds should be called just that. They are not nightly releases.) There's plenty of docs on the Incubator pages about how to do a release. http://incubator.apache.org/guides/releasemanagement.html Note: I expect our first release to be quite painful. It always is. ;) On 24 July 2013 13:35, Kasper Sørensen <[email protected]>wrote: > As far as I can see, we're done with the initial migration to the ASF > infrastructure, namespace etc. > > If you ask me, we can make our first release which isn't much of a change > functionality-wise, but includes the breaking namespace change. > > And in terms of versioning - I believe we should call it version 4.0, since > it breaks backwards compatibility, right? On the other hand I have some > more suggestions for (breaking) improvements to the API that I'd like to > consider once we have JIRA etc. lined up. So maybe we should simply make an > initial release candidate, or alpha release, or what would be a proper > name... > > > 2013/7/18 Kasper Sørensen <[email protected]> > > > It would be great to get that module completed, yes [1]. But we also want > > to release as soon as possible to show renewed activity. I imagine the > > HBase module will take some more time to review and fix, since there's > > still quite some critical pieces missing I think. > > > > [1] Draft module by Sameer and me available at > > http://eobjects.org/svn/MetaModel/branches/HBase-module/hbase/ > > > > > > 2013/7/18 sameer arora <[email protected]> > > > >> I think adding the Hbase module which is lying incomplete for a while > now > >> in the first release > >> > >> > >> On Thu, Jul 18, 2013 at 3:18 PM, Kasper Sørensen < > >> [email protected]> wrote: > >> > >> > The more I think about this (and the work involved, and the postponing > >> of > >> > the migration pain etc. etc.) I feel that we should just do a clean > cut > >> and > >> > break backwards compatibility with the namespace change. It's IMO a > >> choice > >> > of a lot of compiler errors or a lot of deprecation warnings. And my > >> > experience has been that deprecation warnings are a lot worse since > they > >> > take longer to fix :-) > >> > > >> > If we get really critical bugfixes, I imagine that we will still > support > >> > the org.eobjects codebase via the old infrastructure for a while (some > >> > months). If not anything else, then we need that at Human Inference > >> because > >> > our internal migrations are also bound to release cycles other than > >> > MetaModel's. > >> > > >> > > >> > 2013/7/8 Arvind Prabhakar <[email protected]> > >> > > >> > > Accidentally pasted the wrong URL. The correct one is: > >> > > > >> > > [1] > >> > https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration > >> > > > >> > > Regards, > >> > > Arvind Prabhakar > >> > > > >> > > On Mon, Jul 8, 2013 at 2:24 AM, Arvind Prabhakar <[email protected] > > > >> > > wrote: > >> > > > >> > > > 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 > >> > > >> > > >> > > >> > >> > > > > >> > > > > >> > > > >> > > >> > > > > > -- NS
