> > If I look at the migration case, I am tempted to do a one-time move
> to
> > 4.0.x.x (stable) and 4.1.x.x (devel) and drop the v3 tree (flagged
as
> > interim devel release) to prevent any confusion about version
> numbers.
> > Changing from a 3-number to a 4-number scheme within the same major
> > release sounds confusing in itself to me.
>
> I support the suggestion above. Trying to number within v3
> is going to wreak havoc on attempts to update properly.
>
> p.s. To be perfectly honest, I didn't think a move to
> 4-number was even necessary,
I thought quite a while over your message. I have to admit that I
personally would prefer a three-number scheme. Maybe there is a solution
without going overboard on the major version number increments. First of
all, things become stable because bugs are fixed - and no new ones
added. "No new ones added" means every stable version is a dead-end when
it comes to features.
So, 2.0.4 may become 2.0.9 or even 2.0.9999, but we won't see a 2.1.x as
that would imply a sufficiently large new feature. This is also a quite
hard limit as it means the stable version will always starve for new
features. But that's how it works today.
In devel, the minor is updated whenever something cool enough is added
to justify that. Which means typically every 2 to 6 weeks on the current
schedule. So 3.10.0 has become 3.10.2, later 3.11.0 and we are now
(soon;)) at 3.12.5.
The interesting thing is what happens next: 3.12.5 is quite stable now.
There are some feature introduced in 3.10.0 being very stable, some from
3.11.0 which are the same and there as some new ones in 3.12.0
introduced which are not as stable as others (because of limited
exposure to practice). Anyhow, I'll soon convert that whole version to
4.0.0 (maybe 4.0.0.0) stable. Then I'll start a new devel branch and the
stable build again begins to mature but also become feature-less
compared to the devel - which has various stages of maturity some time
later.
I now got a new school of thinking: let's stick with the 3-digit scheme:
major.minor.patchlevel
Major will be incremented whenever there is sufficiently large change
(typically some inner workings must be changed quite a bit). Stabel and
Devel will coexist within the same major release.
For minor, we have even - stable and odd - devel. Patchlevel again is
smaller magnitude changes within the minor (or evolution of a new
feature not yet announced to be usable). But that doesn't solve my need
to sometimes have two or three devel versions with new features in a
row. To solve that, I suggest that we simply skip the stable releases.
For example:
4.0.0 has been released, 4.1.0 is the new stable. I add relp support in
4.1.0. Then I do some changes and end up at 4.1.4. Then, I decide to do
the new config file format. That'll be 4.3.0. Note that there now is a
stable version missing: we have 4.0.0, 4.1.4 and 4.3.0. I work some more
on devel. Then comes a new feature (let's guess TLS support...). So we
finally have 4.0.0, 4.1.4, 4.3.x and 4.5.x. After a while, I am at 4.5.5
and also got enough bug fixes to think that the feature introduced in
4.3.x is now ready for prime time. Then, I'll release 4.4.0, based on
the 4.3.x codebase (and missing the new 4.5.x feature). With the release
of 4.4.0, bugfixing for 4.0.x will end, as we now have a new stable
version of the v4 branch (but fixes would still be applied to stable
v2). So we end up with
4.0.x (deadend), 4.1.x (dead), NO 4.2.x, 4.3.x (dead), 4.4.x (current
stable v4) and 4.5.x (current stable v5).
The key thing is that I left out 4.2.x. If that seems to be acceptable,
we do not need the 4-number scheme.
I know it's pretty wild with all these version numbers... I hope I still
could get the idea over. Feedback is highly appreciated. If there is
none and no objection by next week Tuesday, I'll go for that scheme. I
intend to release 4.0.0(.0) next Wednesday. Today's release of 3.12.5
will set the stage for it.
> but I think you'd know better
> than anyone else what is in the pipeline for rsyslog, and if
> those are major enough to require "major" number to be
> changed, then, yeah, it wouldn't make sense to see 10.x.x
> within a year or two.
Just some thoughts of the pipeline. No guarantees on the order, but the
order is current thinking:
* relp support
* relp with TLS support (followed by relp/GSSAPI)
* config file format (scriptable, RainerScript)
* email notification output
* native TCP w. TLS/syslog-transport-tls internet draft
* cryptographically signed messages
* support for other message types but syslog
* tamperproof (compliance-compliant ;)) system that
forces rsyslogd to work with a centralized configuration
and provides the ability to detect unauthorized client
configuration changes (where they can't be prevented)
... and probably much more ;)
Rainer
> to
> > 4.0.x.x (stable) and 4.1.x.x (devel) and drop the v3 tree (flagged
as
> > interim devel release) to prevent any confusion about version
> numbers.
> > Changing from a 3-number to a 4-number scheme within the same major
> > release sounds confusing in itself to me.
>
> I support the suggestion above. Trying to number within v3
> is going to wreak havoc on attempts to update properly.
>
> p.s. To be perfectly honest, I didn't think a move to
> 4-number was even necessary,
I thought quite a while over your message. I have to admit that I
personally would prefer a three-number scheme. Maybe there is a solution
without going overboard on the major version number increments. First of
all, things become stable because bugs are fixed - and no new ones
added. "No new ones added" means every stable version is a dead-end when
it comes to features.
So, 2.0.4 may become 2.0.9 or even 2.0.9999, but we won't see a 2.1.x as
that would imply a sufficiently large new feature. This is also a quite
hard limit as it means the stable version will always starve for new
features. But that's how it works today.
In devel, the minor is updated whenever something cool enough is added
to justify that. Which means typically every 2 to 6 weeks on the current
schedule. So 3.10.0 has become 3.10.2, later 3.11.0 and we are now
(soon;)) at 3.12.5.
The interesting thing is what happens next: 3.12.5 is quite stable now.
There are some feature introduced in 3.10.0 being very stable, some from
3.11.0 which are the same and there as some new ones in 3.12.0
introduced which are not as stable as others (because of limited
exposure to practice). Anyhow, I'll soon convert that whole version to
4.0.0 (maybe 4.0.0.0) stable. Then I'll start a new devel branch and the
stable build again begins to mature but also become feature-less
compared to the devel - which has various stages of maturity some time
later.
I now got a new school of thinking: let's stick with the 3-digit scheme:
major.minor.patchlevel
Major will be incremented whenever there is sufficiently large change
(typically some inner workings must be changed quite a bit). Stabel and
Devel will coexist within the same major release.
For minor, we have even - stable and odd - devel. Patchlevel again is
smaller magnitude changes within the minor (or evolution of a new
feature not yet announced to be usable). But that doesn't solve my need
to sometimes have two or three devel versions with new features in a
row. To solve that, I suggest that we simply skip the stable releases.
For example:
4.0.0 has been released, 4.1.0 is the new stable. I add relp support in
4.1.0. Then I do some changes and end up at 4.1.4. Then, I decide to do
the new config file format. That'll be 4.3.0. Note that there now is a
stable version missing: we have 4.0.0, 4.1.4 and 4.3.0. I work some more
on devel. Then comes a new feature (let's guess TLS support...). So we
finally have 4.0.0, 4.1.4, 4.3.x and 4.5.x. After a while, I am at 4.5.5
and also got enough bug fixes to think that the feature introduced in
4.3.x is now ready for prime time. Then, I'll release 4.4.0, based on
the 4.3.x codebase (and missing the new 4.5.x feature). With the release
of 4.4.0, bugfixing for 4.0.x will end, as we now have a new stable
version of the v4 branch (but fixes would still be applied to stable
v2). So we end up with
4.0.x (deadend), 4.1.x (dead), NO 4.2.x, 4.3.x (dead), 4.4.x (current
stable v4) and 4.5.x (current stable v5).
The key thing is that I left out 4.2.x. If that seems to be acceptable,
we do not need the 4-number scheme.
I know it's pretty wild with all these version numbers... I hope I still
could get the idea over. Feedback is highly appreciated. If there is
none and no objection by next week Tuesday, I'll go for that scheme. I
intend to release 4.0.0(.0) next Wednesday. Today's release of 3.12.5
will set the stage for it.
> but I think you'd know better
> than anyone else what is in the pipeline for rsyslog, and if
> those are major enough to require "major" number to be
> changed, then, yeah, it wouldn't make sense to see 10.x.x
> within a year or two.
Just some thoughts of the pipeline. No guarantees on the order, but the
order is current thinking:
* relp support
* relp with TLS support (followed by relp/GSSAPI)
* config file format (scriptable, RainerScript)
* email notification output
* native TCP w. TLS/syslog-transport-tls internet draft
* cryptographically signed messages
* support for other message types but syslog
* tamperproof (compliance-compliant ;)) system that
forces rsyslogd to work with a centralized configuration
and provides the ability to detect unauthorized client
configuration changes (where they can't be prevented)
... and probably much more ;)
Rainer