When do we want to declare a 1.0? When we are running on HDFS-265? When we run on a hdfs that doesnt lose data?
If the latter, then 0.20.5 is a contender. There is a lot of expectation out of a 1.0. Other options are going to an alternate scheme, like "version 20" (eg: oracle 9) but that seems not enough of a distance. I would probably go with something like calling 0.20.5 -> 0.9 then once we are baked, 1.0 later (trunk or branch, not sure, probably trunk) On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <t...@cloudera.com> wrote: > On Fri, Apr 23, 2010 at 12:22 AM, Stack <st...@duboce.net> wrote: > >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray <jg...@facebook.com> >> wrote: >> > Now might also be the time to think about breaking from hadoop numbering >> (I think this idea has been floating around since the first version we >> synced). >> > >> > We've already agreed to break client compatibility for 0.20.5 and it's >> more than a minor revision. And I'm sure we'll have another release between >> 0.20.5 and 0.21. >> > >> >> So, the new version could be 0.21 but thats not 'breaking from hadoop >> numbering' and it can't be 1.0.0 .... yet. What should it be? 0.99.0 >> is kinda dumb. 0.3.0? (We went as far as 0.2.0 on old numbering >> system). 0.3.0 will be less than 0.21.0 so will mess w/ packaging >> systems. 0.30.0? >> >> > Both deb and RPM have the concept of a version epoch, so we can make 0.3.0 > > 0.20 if we like. > > However, it might be confusing for users nonetheless. > > >> >> > It's also clear that this is going to be by far our most solid release to >> date and so might be worthy of new shiny versioning/packaging as a TLP. >> Website/docs/wiki refresher to boot. >> > >> > Changing the package names is way more invasive to client code but I'm >> always +1 on making stuff shorter. >> >> Might have to keep around the old stuff deprecated. >> >> St.Ack >> >> > >> > >> > Anyways, I'm not doing much production cluster maintenance these days so >> these changes would impact me way less than others. Will welcome pushback >> if you guys don't want to deal with this. >> > >> > JG >> > >> >> -----Original Message----- >> >> From: Ryan Rawson [mailto:ryano...@gmail.com] >> >> Sent: Thursday, April 22, 2010 11:20 PM >> >> To: hbase-dev@hadoop.apache.org >> >> Subject: Re: HBase move to Apache Top Level Project >> >> >> >> I am somewhat interested in this :-) >> >> >> >> But it can make life difficult for our users... thoughts people? >> >> >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <oss....@gmail.com> wrote: >> >> > This is great news. Congrats HBase team. >> >> > >> >> > (Does this mean, the packages would be refactored as o.a.hbase.* in >> >> the >> >> > trunk ? ). >> >> > >> >> > -- >> >> > Karthik. >> >> > >> >> > >> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene <cleh...@adobe.com> >> >> wrote: >> >> > >> >> >> This is great news! >> >> >> >> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote: >> >> >> >> >> >> > The board yesterday passed a resolution making HBase a TLP. >> >> >> > >> >> >> > I filed an infrastructure issue to start the move: >> >> >> > >> >> >> > https://issues.apache.org/jira/browse/INFRA-2641 >> >> >> > >> >> >> > The primary disruption to developers will be when the subversion >> >> >> > repository is renamed. We'll send out a note before we do this, >> >> then >> >> >> > developers can use 'svn switch' to update their repos (There is no >> >> >> > apache git repo that I know of... I asked just in case) >> >> >> > >> >> >> We already use the apache git.apache.org mirror for HBase. I've also >> >> seen >> >> >> the GitHub mirror http://github.com/apache/hbase and thought there >> >> might >> >> >> be some plans for migration. >> >> >> >> >> >> > One other issue is the wiki. I don't think it's easy to rename a >> >> >> > subtree from a Moin Moin wiki to a new wiki. Fortunately we don't >> >> >> > have many wiki pages and could cut and paste them manually. >> >> >> > Alternately, we could switch to using confluence for our wiki. >> >> >> > Thoughts? >> >> >> > >> >> >> Confluence has a good integration with Jira (being both developed by >> >> >> Atlassian). It's functionally advanced and looks better. So +1 for >> >> that as >> >> >> well. >> >> >> >> >> >> Cosmin >> >> >> >> >> >> > St.Ack >> >> >> > (Above shamelessly a copy of Doug's mail to the Avro list) >> >> >> >> >> >> >> >> > >> > >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
