cleaning them up sounds like a good idea, but bulk version shifts are always a nightmare. Probably some version rename will be the least painful way to fix it.
On Tue, Jun 20, 2017 at 10:27 PM, Phil Yang <ud1...@gmail.com> wrote: > Or we can just rename 2.0.0 version to alpha-1 and delete the current > alpha-1 and move issues under old alpha-1 to new one? > > Thanks, > Phil > > > 2017-06-21 11:20 GMT+08:00 Phil Yang <ud1...@gmail.com>: > >> In JIRA there are many resolved issues whose fix version is 2.0.0, they >> are "released" when 2.0.0-alpha-1 released, do we need change them to >> 2.0.0-alpha-1? 2.0.0 should be a formal version after alpha/beta? >> >> Thanks, >> Phil >> >> >> 2017-06-21 1:00 GMT+08:00 Stack <st...@duboce.net>: >> >>> Thanks Josh. >>> >>> Sean noticed that I'd not actually pushed the alpha to our release dir. >>> Just did that. >>> >>> St.Ack >>> >>> On Tue, Jun 20, 2017 at 9:58 AM, Josh Elser <josh.el...@gmail.com> wrote: >>> >>> > Done ;) >>> > >>> > There were two issues still tagged as alpha-1 (JIRA didn't want to show >>> me >>> > them before performing the action), but I bumped them to alpha-2. >>> > >>> > >>> > On 6/20/17 12:19 PM, Mike Drob wrote: >>> > >>> >> Hi Stack, >>> >> >>> >> Can you mark jira version 2.0.0-alpha-1 as released? >>> >> >>> >> Thanks, >>> >> Mike >>> >> >>> >> On Sat, Jun 10, 2017 at 10:55 PM, Stack <st...@duboce.net> wrote: >>> >> >>> >> With 4 binding votes and 1 non-binding, vote passes. Let me push out >>> the >>> >>> alpha. >>> >>> Thanks to all who voted. >>> >>> St.Ack >>> >>> >>> >>> >>> >>> On Sat, Jun 10, 2017 at 11:40 AM, Stack <st...@duboce.net> wrote: >>> >>> >>> >>> Great. Thanks Sean. In-line... >>> >>>> >>> >>>> On Fri, Jun 9, 2017 at 11:35 PM, Sean Busbey <bus...@apache.org> >>> wrote: >>> >>>> >>> >>>> +1 >>> >>>>> >>> >>>>> details below, a few things to clean up for later alpha/betas. >>> >>>>> >>> >>>>> * checksums are all good >>> >>>>> * signatures are made with two different keys. should clean up by >>> next >>> >>>>> alpha. >>> >>>>> >>> >>>>> src / bin artifacts are signed with 8ACC93D2, as you mentioned in >>> the >>> >>>>> VOTE. However, this key is not in our project's KEYS file. >>> >>>>> >>> >>>>> >>> >>>>> Yes. Will fix. >>> >>>> >>> >>>> >>> >>>> maven staged repository are signed with 30CD0996, which is in our >>> KEYS >>> >>>>> file so those check out fine. >>> >>>>> >>> >>>>> * the tag 2.0.0-alpha-1RC0 does point to >>> >>>>> c830a0f47f58d4892dd3300032c8244d6278aecc, which matches the source >>> >>>>> artifact after accounting HBASE-13088 >>> >>>>> >>> >>>>> The tag isn't signed; would be good to make sure we do tag signing >>> in >>> >>>>> betas so that it's ready to go come GA time. >>> >>>>> >>> >>>>> >>> >>>>> Next time through, I'll update our 'How to RC' doc and will add >>> above. >>> >>>> >>> >>>> >>> >>>> >>> >>>> (side note, it would be good to get a decision on HBASE-13088 for the >>> >>>>> beta releases. been over 2 years) >>> >>>>> >>> >>>>> * the source tarball creates a binary assembly that looks as close >>> to >>> >>>>> the posted binary artifact as I've seen branch-1 do. >>> >>>>> >>> >>>>> idle interest, but our binary convenience artifact has jumped from >>> >>>>> ~100MiB in branch-1 release to ~160MiB. If anyone has time to dig in >>> >>>>> on why, probably worth checking. (e.g. the docs directory is ~585 >>> MiB >>> >>>>> when untared.) >>> >>>>> >>> >>>>> >>> >>>>> Yes. Its obnoxious (HBASE-18208). >>> >>>> >>> >>>> >>> >>>> * shaded artifact binaries are a reasonable number of MiB in size >>> >>>>> (incorrect build flags will result in ~empty jars) >>> >>>>> >>> >>>>> * LICENSE/NOTICE spot check looks okay. >>> >>>>> >>> >>>>> we have a ton of places where we have velocity variables instead of >>> >>>>> copyright years, but IIRC that's a problem on branch-1 right now >>> too. >>> >>>>> >>> >>>>> * CHANGES file hasn't been updated correctly >>> >>>>> >>> >>>>> currently has details for 0.93. >>> >>>>> >>> >>>>> >>> >>>>> Will fix next time through. >>> >>>> >>> >>>> Thanks Sean, >>> >>>> S >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Jun 9, 2017 at 12:06 PM, Andrew Purtell <apurt...@apache.org >>> > >>> >>>>> wrote: >>> >>>>> >>> >>>>>> +1 >>> >>>>>> >>> >>>>>> On Thu, Jun 8, 2017 at 12:33 AM, Stack <st...@duboce.net> wrote: >>> >>>>>> >>> >>>>>> The first release candidate for HBase 2.0.0-alpha-1 is up at: >>> >>>>>>> >>> >>>>>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0- >>> >>>>>>> >>> >>>>>> alpha-1RC0/ >>> >>> >>> >>>> >>> >>>>>>> Maven artifacts are available from a staging directory here: >>> >>>>>>> >>> >>>>>>> https://repository.apache.org/content/repositories/orgapache >>> >>>>>>> >>> >>>>>> hbase-1169 >>> >>>>> >>> >>>>>> >>> >>>>>>> All was signed w/ my key 8ACC93D2 >>> >>>>>>> <http://pgp.mit.edu/pks/lookup?op=get&search=0x9816C7FC8ACC93D2> >>> >>>>>>> >>> >>>>>>> I tagged the RC as 2.0.0-alpha-1RC0 >>> >>>>>>> (c830a0f47f58d4892dd3300032c8244d6278aecc). >>> >>>>>>> >>> >>>>>>> hbase-2.0.0-alpha-1 will be our first 2.0.0 release. It is a rough >>> >>>>>>> >>> >>>>>> cut >>> >>> >>> >>>> ('alpha') not-for-production preview of what hbase-2.0.0 will look >>> >>>>>>> >>> >>>>>> like. It >>> >>>>> >>> >>>>>> is what we used to call a 'Developer' release[1] meant mostly for >>> >>>>>>> >>> >>>>>> devs >>> >>> >>> >>>> and >>> >>>>> >>> >>>>>> downstreamers to test drive and flag us early if we there are >>> issues >>> >>>>>>> >>> >>>>>> we’ve >>> >>>>> >>> >>>>>> missed ahead of our rolling a production-worthy release. >>> >>>>>>> >>> >>>>>>> hbase-2.0.0 includes a fleet of new features that include a new >>> >>>>>>> >>> >>>>>> assignment >>> >>>>> >>> >>>>>> manager, means for keeping read and write path off-heap, in-memory >>> >>>>>>> compactions, and more. I have been keeping a running doc on the >>> state >>> >>>>>>> >>> >>>>>> of >>> >>>>> >>> >>>>>> 2.0.0 here [2]. There is much to do still (see aforementioned doc). >>> >>>>>>> >>> >>>>>>> The list of features addressed in 2.0.0 so far can be found here >>> [4]. >>> >>>>>>> >>> >>>>>> There >>> >>>>> >>> >>>>>> are about 2500. The list of ~500 fixes in 2.0.0 exclusively can be >>> >>>>>>> >>> >>>>>> found >>> >>>>> >>> >>>>>> here [3]. >>> >>>>>>> >>> >>>>>>> Please take it for a spin and vote on whether it ok to put out as >>> our >>> >>>>>>> >>> >>>>>> first >>> >>>>> >>> >>>>>> alpha (bar is low for an 'alpha'). Let the VOTE be open for 24 >>> hours. >>> >>>>>>> >>> >>>>>>> Thanks, >>> >>>>>>> St.Ack >>> >>>>>>> >>> >>>>>>> 1. http://hbase.apache.org/book.html#hbase.versioning.pre10 >>> >>>>>>> 2. >>> >>>>>>> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ >>> >>>>>>> ktczrlKHK8N4SZzs/edit#heading=h.v21r9nz8g01j >>> >>>>>>> 3. >>> >>>>>>> https://issues.apache.org/jira/browse/HBASE-17852?jql= >>> >>>>>>> project%20%3D%20HBASE%20%20and%20fixVersion%20%3D%202. >>> >>>>>>> 0.0%20and%20fixVersion%20not%20in%20(1.0.0%2C%201.0.1%2C% >>> >>>>>>> 201.0.2%2C%201.0.3%2C%201.0.4%2C%201.0.5%2C%201.0.6%2C%201. >>> >>>>>>> 1.0%2C%201.1.1%2C%201.1.2%2C%201.1.3%2C%201.1.4%2C%201.1.5% >>> >>>>>>> 2C%201.1.6%2C%201.1.7%2C%201.1.8%2C%201.1.9%2C%201.1.10%2C% >>> >>>>>>> 201.2.0%2C%201.2.1%2C%201.2.2%2C%201.2.3%2C%201.2.4%2C%201. >>> >>>>>>> 2.5%2C%201.2.6%2C%201.3.0%2C%201.3.1%2C%201.4.0)%20and%20% >>> >>>>>>> 20(status%20%3D%20Open%20or%20status%20%3D%20%22Patch% >>> >>>>>>> >>> >>>>>> 20Available%22) >>> >>> >>> >>>> 4. >>> >>>>>>> https://issues.apache.org/jira/browse/HBASE-18191?jql= >>> >>>>>>> project%20%3D%20HBASE%20%20and%20(%20fixVersion%20%3D% >>> >>>>>>> 202.0.0)%20and%20(status%20%3D%20Resolved) >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Best regards, >>> >>>>>> >>> >>>>>> - Andy >>> >>>>>> >>> >>>>>> If you are given a choice, you believe you have acted freely. - >>> >>>>>> >>> >>>>> Raymond >>> >>> >>> >>>> Teller (via Peter Watts) >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>> >>> >> >>> >> >> -- Sean
