I've created umbrella issues for 1.x and 2.0.0 2.0.0: https://issues.apache.org/jira/browse/HBASE-13462 1.x: https://issues.apache.org/jira/browse/HBASE-13465
On Tue, Apr 14, 2015 at 12:42 PM, Lars Francke <lars.fran...@gmail.com> wrote: > Okay I'll go with another option. As I don't have as much time as I'd like > to I'll just split this into arbitrary chunks and will create a new JIRA > every time I'll have to stop working on this. Fortunately this stuff is > independent and easily done in small increments. > > I'll create the first JIRAs and post patches now. > > On Tue, Apr 7, 2015 at 10:29 PM, Lars Francke <lars.fran...@gmail.com> > wrote: > >> Hmm...that'd work too but is a bit more arbitrary as some patches were >> cross-cutting...I don't really have an opinion though :) >> >> On Tue, Apr 7, 2015 at 3:31 PM, Sean Busbey <bus...@cloudera.com> wrote: >> >>> How about an issue per module? Should end up being somewhere between >>> those >>> two. >>> >>> -- >>> Sean >>> On Apr 7, 2015 7:21 AM, "Lars Francke" <lars.fran...@gmail.com> wrote: >>> >>> > Great, thanks everyone for your input. >>> > >>> > I started to go through the issues. >>> > >>> > I see two options: 1) One issue per "source" issue or 2) one issue per >>> > version. >>> > >>> > Examples: >>> > 1) Create new issues like this "Handle deprecations for HBASE-9870" and >>> > then attach two patches (one for branch-1 and one for master, >>> documenting >>> > deprecation and removing them respectively). This would mean lots of >>> small >>> > issues, easy to review, easy to keep updated, easy to commit. Collect >>> them >>> > all in an umbrella issue. >>> > >>> > 2) Create a new issue "Document deprecations in branch-1" and another >>> one >>> > "Remove deprecations for 2.0.0" with a big patch attached to each. >>> > >>> > I prefer version 1 even though it'd be a lot of small patches. Release >>> > notes could be per issue or collected in an umbrella issue. >>> > >>> > Any opinions? If I don't hear any I'll go ahead with that and will >>> start >>> > filing. >>> > >>> > Cheers, >>> > Lars >>> > >>> > >>> > >>> > On Mon, Apr 6, 2015 at 8:42 PM, Stack <st...@duboce.net> wrote: >>> > >>> > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <bus...@cloudera.com> >>> wrote: >>> > > >>> > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke < >>> lars.fran...@gmail.com> >>> > > > wrote: >>> > > > >>> > > > > Thanks Lars. Any other opinions, any more input? >>> > > > > >>> > > > > If not I hope to have some time this week to work on these >>> points: >>> > > > > >>> > > > > * In the master branch (which will be released as 2.0.0 if I'm >>> not >>> > > > > mistaken) remove (or undeprecate if it turns out the >>> functionality is >>> > > > > actually still needed) all functionality that was marked >>> deprecated >>> > > prior >>> > > > > to 1.0.0 >>> > > > > * Clarify that all deprecations that were added in 1.x will be >>> > removed >>> > > in >>> > > > > 3.0.0 (using JavaDoc and in the book) >>> > > > > * Clarify that all deprecations that were added in 2.x will be >>> > removed >>> > > in >>> > > > > 4.0.0 (using JavaDoc and in the book) >>> > > > > * Clarify the SemVer documentation with a different example >>> > > > > >>> > > > > I'd rather not do unnecessary or unwanted work :) >>> > > > > >>> > > > > >>> > > > >>> > > > FWIW, this works for me. The lack of complaints leads me to >>> believe it >>> > > > works for other PMCs. ;) >>> > > > >>> > > > >>> > > Works for me (though quiet, have been following closely -- as are >>> others >>> > > I'd think). >>> > > >>> > > >>> > > >>> > > >>> > > > Please make sure these removals have good release notes. Folks who >>> know >>> > > > what their API usage looks like should have a heads up prior to >>> > > > recompiling. (I'm happy to help iterate on release notes once you >>> get >>> > to >>> > > > that point.) >>> > > > >>> > > > >>> > > Good idea (umbrella issue to tie the efforts together). >>> > > >>> > > Thanks LarsF, >>> > > St.Ack >>> > > >>> > >>> >> >> >
