[PROPOSAL] Release ldb with Samba on the 6-montly release cycle
abartlet at samba.org
Thu Apr 11 19:34:34 UTC 2019
On Thu, 2019-04-11 at 15:27 +0200, Andreas Schneider via samba-
> On Thursday, April 11, 2019 10:36:59 AM CEST Andrew Bartlett via
> technical wrote:
> > Looping back to the top of this thread to put a reduced proposal.
> > I've posted a new merge request here:
> > https://gitlab.com/samba-team/samba/merge_requests/374
> > The scope is reduced to aligning the ldb version with the main
> > Samba
> > version, so ldb would share the Samba release cycle. There is no
> > merge
> > with the main Samba build, just a change to the version number
> > calculations (and so release process).
> > The primary motivation here is to decouple ABI changes (eg adding a
> > new
> > function) from release points, and so slowing down to a 6-month
> > release
> > cycle matching the main release cadence of Samba so that new
> > features
> > have time to bake in master before they are released.
> Yes, I absolutely agree that SO_VERSION number should be decoupled
> release version numbers. This should also be done for the other
> If I understand you correctly there will be a libldb release:
> libldb-4.11 and then libldb-4.12
> Samba 4.11.1 and 4.11.2 will depend on libldb-4.11.
The current WIP patch has the main Samba version string directly used
for ldb, therefore allowing ldb to change during a release stream (eg
for a security release).
Please look carefully at the MR for the details, I would certainly not
wish any more miscommunication!
> If I understood it correctly than this sounds like a good idea! :-)
Great! I was sure we could find some common ground.
So from here we just need to know if this (eg) libldb-4.11 needs a
distinct tarball to be generated by the release team.
Now that we are clear on what is being talked about, I have also re-
If we decide not to burden the release team with a distinct tarball,
then distributors building ldb would just need to use the main samba
tarball and add a 'cd lib/ldb' to their build scripts.
Finally, this is all just WIP proposals, other variations on this
approach are most welcome. But if you do agree with any of the above
please mark that on the relevant MR so I can keep track.
Thank you very much for your thoughtful consideration of the above,
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical