Re: Versioning scheme for rdma-plumbing

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Sep 14, 2016 at 11:15:09PM -0700, Christoph Hellwig wrote:
> On Wed, Sep 14, 2016 at 11:33:27AM -0600, Jason Gunthorpe wrote:
> > >  - it allows for much smoother minor updates.  I hope this will be
> > >    rare, but my experience from various projects tells me that they
> > >    will occasionally be needed.
> > 
> > Can you explain this some more?
> > 
> > If we use a single integer ala udev, I'd see minor updates, LTS
> > branch, etc being released with a suffix eg: 123.2
> 
> Well, that's not a monotonically increasing version number anymore.
> And at least in the past systemd folks argued against even doing these
> releases.  If you're fine with doing minor releases off these single
> component versions this argument goes away of course.

Yah, I wouldn't as strict as what you are describing.

The 'single integer' is really semantic versioning with the 'MAJOR'
stripped off, since a project goal is to not make incompatable
changes.

Most upstream releases should be of the 'add functionality in a
backwards-compatible manner' and should just increment the
integer. Upstream can always increment the integer

If upstream botches a release then it might make a quick 123.1, but
generally upstream would not be in the buisness of backporting fixes
from N to N-1.

*However* I think we should make room for the people to collaborate
on a LTS branch that would use the .X nomenclature. Much like in the
kernel Linus doesn't maintain the -stable, but makes space for the
people who do.

eg perhaps the OFED team would be willing to direct their energies
upstream and maintain a public stable branch for the duration of their
release cylce ?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html