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 <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: > > > > > On Mon, Apr 6, 2015 at 8:20 AM, Sean Busbey <[email protected]> > wrote: > > > > > > > On Mon, Apr 6, 2015 at 6:54 AM, Lars Francke <[email protected] > > > > > > 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 > > > > > >
