Hi Arvind and Cheolsoo,
thank you very much for your feedback, I really appreciate that. I definitely agree that we should document the versions on the wiki and I'll do it myself once it will become relevant.
I would personally incline to let the discussion when to switch from 1.99.x to 2.y open and simply upgrade number to 2.y when developers will feel it's the right time. I would personally like to see following resolved before going to 2.0.0:
* Have pretty good coverage of most important features available in sqoop 1 - import + export tools. Support export to Hive, HBase and Avro. Support incremental imports, query and table based imports. Support update based export.
* Get clear picture how metadata upgrade will be performed
* Get working oozie integration
* Have a very good test coverage in place
* Do performance tests and performance comparison with Sqoop 1
* Have some beta testing done with some adventurous users to make sure that it's both easily usable and working in pseudo production environments
On Tue, Oct 23, 2012 at 09:38:17AM -0700, Arvind Prabhakar wrote:
> Hi Jarcec,
> Thanks for the suggestion, and apologies for the late response. I too feel
> that having version number is better than label qualifiers such as alpha.
> Overall, I like this proposal and think it will be useful for our
> community. I have a couple of optional suggestions to go with it:
> 1. We create a page on our Wiki that details this scheme so that users can
> understand what state a release is in, and
> 2. Have a criteria established for switching over to the 2.0.0 version
> Of course, we can address these independent of adopting the version scheme,
> so it does not have to be blocked on anything.
> Arvind Prabhakar
> On Fri, Oct 19, 2012 at 10:16 AM, Cheolsoo Park <[EMAIL PROTECTED]>wrote:
> > Hi Jarcec,
> > I like your suggestion of 1.99.x. That seems intuitive and clear what it's
> > supposed to mean to me.
> > Thanks,
> > Cheolsoo
> > On Fri, Oct 12, 2012 at 1:42 PM, Jarek Jarcec Cecho <[EMAIL PROTECTED]
> > >wrote:
> > > Hi Sqoop(2) developers,
> > > we're making very good progress in Sqoop 2 land. Current code base still
> > > can't move any data around, but I'm sure that we're very close to have
> > > something usable and testable soon. With this regard, I would like to
> > > propose doing some
> > > pre/alpha/beta/unstable/preview/pick-your-own-word-for-unstable-code
> > > release as soon as possible to provide early adopters first testable
> > bits.
> > > My motivation to provide early bits is to get feedback from actual users
> > as
> > > soon as possible, so that we can incorporate good ideas before it will
> > > become too expensive.
> > >
> > > However releasing such early state raises question what version should we
> > > release. I would say that most simple idea is to release version "2.0.0",
> > > however due to unstable nature, I believe that it's very bad idea. Hadoop
> > > seems to be adding "-alpha" to the version names, for example
> > > "2.0.1-alpha". I don't quite like this solution as I would personally
> > > expect that there will be 2.0.1 stable (without "alpha" suffix) that
> > won't
> > > have any new features but will be stable soon. As this won't be the case
> > > for Sqoop, I would like to propose slightly different solution that I've
> > > seen in some other projects. I would like to propose doing release
> > 1.99.1.
> > > I believe that the version number implies that it's very far from current
> > > stable 1.4 version and very very near to 2.0, but it's not 2.0 yet. I
> > would
> > > like to see other opinions about using 1.99.1 version for first cut of
> > our
> > > Sqoop 2 branch.
> > >
> > > I actually did not invent this idea - I've seen in before. For example
> > KDE
> > > project  is using very similar approach for quite some time by now as
> > > you can see on their archive . Versions like 4.8.90 or 4.8.95 are
> > > "pre-releases" for 4.9. Another example would be Ubuntu one client .