maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxxx>]

Hi, Henrik!

On May 05, Henrik Ingo wrote:
> >
> > I think we very nearly made the same mistake with 5.2. We had a
> > feature list, and while some of them were "rolling", we also had
> > features that were decided in advance that they _must_ be pushed at
> > a certain date. I strongly believe this is wrong. We should have
> > made _all_ features rolling.
> 
> I think everyone *says* they agree with above.

Not everyone. I certainly disagree. I think there could be both "must
have" and rolling features - unless there are "must have" features, you
cannot promise anything to your customers, and they cannot plan their
development.

"All features are rolling" is as bad as "a release will be ready when it
will be ready" - neither promises anything, and neither produces
anything customers can rely upon.

> You're right that we did drive 5.2 a bit differently.

And it worked quite well.

The problem is not that there are "must have" feature, the problem (that
MySQL was making every single release) that there are too many of them.
We did not make this mistake in 5.2 and it worked out fine.

In fact, it would've been much worse if all features were rolling -
if they were, we'd release 5.2 in April 1st, as originally planned,
and it would have only half the features it got, we would have no story
for the Storage Engine Summit (and only vaporware for the plugin UC
talk).

But as plugin features were "must have" we delayed the release for one
week, and they all made it in.

> > So rather than go to MariaDB 5.2, we could imagine something like this:
> >
> >    MariaDB 5.1.44-1       Current MariaDB 5.1.44
> >    MariaDB 5.1.44-2       Current MariaDB 5.2.0
> >    MariaDB 5.1.44-1.1     In case we need to do a bugfix for 5.1.44-1
> >    MariaDB 5.1.46-1       Next time we merge MySQL 5.1.46 into MariaDB -1
> >    MariaDB 5.1.46-2       Next time we merge MySQL 5.1.46 into MariaDB -2

That would be difficult.

We cannot just make up any numbering scheme we want - it must fit into
what distributions and various package managers expect from a version
number.

And as far as I understand, the usual expectations are - three numbers
as a version, an optional suffix, and a local (distribution specific)
revision number.

I'm not sure the sufix is always significant, that is, I don't know how
they treat two releases that have exactly the same version number, but
different suffixes. In MySQL the suffix (-alpha, -beta) was  not
significant, and I don't remember if there was a reason for it or not.

Regards,
Sergei