Right, that's my perception on that too. -Mikhail
On Tue, Apr 14, 2015 at 9:50 AM, Nick Dimiduk <[email protected]> wrote: > On Thu, Apr 9, 2015 at 12:44 AM, Mikhail Antonov <[email protected]> > wrote: > >> 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? >> > > I believe you have the right of it. Just because we can remove arbitrarily > doesn't mean we should. I don't think you'll see a policy resolve from this > thread, though the consensus seems to be "remove with caution". Probably > the best approach is to file tickets per domain, mark them for 2.0, and > decisions will be made locally. > > On Tue, Apr 7, 2015 at 1:29 PM, Lars Francke <[email protected]> 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 <[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 >> >> > > >> >> > >> >> >> >> >> >> -- >> Thanks, >> Michael Antonov >> -- Thanks, Michael Antonov
