How to move storage OEMs to Samba 4.0 ?

Jeremy Allison jra at
Wed Jun 6 10:10:31 MDT 2012

On Wed, Jun 06, 2012 at 08:30:05AM -0400, simo wrote:
> I tend to agree that it really depends on how and what we add.
> But I am ok if the new features do not change behavior or break existing
> systems.

This is the thing I'd like to get agreement on. For the next year
I'd like to loosen up the restrictions on new features in 3.6.x.

Not to go hog-wild, just to allow the useful life of 3.6.x to
be extended while we get people to move over to 4.0.

> I think we cna strike a compromise for minor features that have
> absolutely no impact on existing functionality.

+1 - that's what I'm proposing really.

> I agree on this one, no more 3.x releases once we decide 4.0 is good to
> go.

OK - I get the Team feelings on this loud and clear :-).

> The situation is different though, the architectural changes to the file
> server were dramatic back then. Right now the architectural difference
> in the file server between master and 3.6 are not so big, which makes it
> tempting to try to backport stuff.
> We should probably resist the temptation.

Depending on the feature :-).

> I think we can make OEMs life better if we provide a --file-server-only
> build that will have the same dependencies and footprint of the current
> file server. (well except for python, but that's fine)
> I think that would go to great lengths to make it easier for OEMs to
> adopt 4.0 for their file server needs.

It will take 1+ years for OEMs to move. That's just the truth of it.

No OEM will trust 4.0.x for production use for a year. That's not
to say it's bad code, or doesn't have more stability than 3.6.x,
it's just the way people are.

If we're lucky some adventurous OEMs will be testing 4.0.x in
internal "test" builds 6+ months from now.


More information about the samba-technical mailing list