I'm probably late to this thread, but just given some comments to HBASE-13395 wanted to follow up here.
Semver states that "MAJOR version when you make incompatible API changes". I read it literally as "in 2.0 you can remove anything compared to 1.0". Realistically, that probably means we can at least remove APIs which could be relatively easily replaced on the user side following the release notes? Am I interpreting this incorrectly? -Mikhail On Tue, Apr 7, 2015 at 1: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 >> > > >> > >> -- Thanks, Michael Antonov
