But isn't it all meaningless unless those numbers mean something? For eg. in case of HBase, they govern our compat and in turn, what gets backported, which gives them huge significance.
I think, one way or other, they will get meaning - Either we actively give them now, or they take it overtime :) Going this way, i.e. deciding what's major or minor enough will require discussion every time, and seems like the latter of the above mentioned two ways. We'll take decision on per case basis and eventually look back on how to make it simpler. But like pointed earlier - these are all internal and putting in much time into it will be waste when we can get away in simpler ways. So I for one, would like to give them a simple meaning. Here's an initial suggestion: - Tie down major versions : We know we'll be updating at least some of these libs every major version of HBase, so it'll require new release. - Free form minor version: Minor release of HBase can take the latest minor release of third-party. - Get rid of maintenance versions: Earlier i was thinking to tie both major and minor, but considering that we might not update anything in a minor release of HBase, either then minor version will get decoupled, or we'll have to do bogus third-party:x.x.0 release corresponding to HBase:x.x.0 release just to match minor verison. There can be other ways, this is just an initial suggestion. -- Appy On Tue, Nov 28, 2017 at 8:06 PM, Mike Drob <md...@apache.org> wrote: > I think it is coincidental in this case, and we actively wouldn't want to > peg them. > > On Tue, Nov 28, 2017 at 6:21 PM, Jerry He <jerry...@gmail.com> wrote: > > > Is it an intention to use the same version as hbase 2. Or is it just > > coincidental, and we can not really peg them? > > > > On Tue, Nov 28, 2017 at 4:08 PM Josh Elser <els...@apache.org> wrote: > > > > > > > > > > > On 11/28/17 4:54 PM, Stack wrote: > > > > On Tue, Nov 28, 2017 at 1:14 PM, Mike Drob <md...@apache.org> wrote: > > > > > > > >> Wanted to get some input on the versioning scheme for our > > > hbase-thirdparty > > > >> artifacts. > > > >> > > > >> We are moving all of the relocation from o.a.h.shaded to > > > o.a.h.thirdparty > > > >> due to conflicts with our non-thirdparty shaded libraries. > Currently, > > > the > > > >> next release is slated to be of the thirdparty libs is slated to be > > > 1.0.2, > > > >> however the package change seems like a big deal. > > > >> > > > >> I propose that we go to 1.1.0 or 2.0.0 even with this. Version > numbers > > > are > > > >> cheap, we won't run out, so we can afford to be aggressive with > > > >> incrementing them. And we don't have to worry about other users of > > this, > > > >> since it's all designed to be internal. > > > >> > > > >> Thoughts? > > > >> > > > >> > > > > 2.0.0 > > > > > > +1 > > > > > > -- -- Appy
