On Wed, Jul 24, 2013 at 8:31 AM, Noah Slater <[email protected]> wrote:
> 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, We should look into using the svn pub-sub staging area for releases (the dist area is required for approved releases already) rather than anything on people.apache.org > and call a vote. But we must not call these > To be clear, the vote needs to have both PPMC and Incubator PMC approval (IPMC). All of the mentors are IPMC members, so assuming we all vote +1 for the release, we only need to ask general@ for lazy consensus. For anyone unfamiliar with lazy consensus, it is a powerful concept employed heavily at the ASF[1] > 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. > Assuming we are deploying to the Nexus Maven repository, we can have the CI engine deploy SNAPSHOTS to repository.apache.org. > > http://incubator.apache.org/guides/releasemanagement.html We should document our release process on the website the first time we run through it [2] [3]. [1] http://rave.apache.org/docs/governance/lazyConsensus.html (there is a comdev page, I just found this one first) [2] http://bval.apache.org/release-management.html [3] http://rave.apache.org/release-management.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 >
