We originally planned to release a new major version every 6 month and a new minor version every month. So yeah, it's probably more correct to say we release every month...

Redmine never had a 6 month release goal. This is something we do exclusively at ChiliProject :) But even this schedule is a bit shaky currently, due to some major planned cleanup work, which will probably lead to an earlier 2.0 release.

Thanks for clearing that up, Holger.

Is there any reason why the release schedule needs to be mentioned at all in that section of the wiki, though? It just seems a hostage to fortune. It also violates DRY :)

I also see now that the release schedule page is out of date. I guess that's also a result of violating DRY. Given that this web page already provides the release dates, I think it's probably not the best idea to manually copy them into the wiki. Better just to provide a link...

I've made a start on fixing this by making the "Which version to choose" section much more concise. Hope you approve of my edit!

Thanks again :)

Sam Kuper wrote:

I also see now that the release schedule page is out of date. I guess that's also a result of violating DRY. Given that this web page already provides the release dates, I think it's probably not the best idea to manually copy them into the wiki. Better just to provide a link...

I've now had a go at fixing this. Hope you don't mind that I overwrote an edit you made shortly before mine! :)

Hi Holger,

I'm a bit puzzled by your latest edit to the release schedule page.

For instance, it suggests (in the second table) that only 1.1.0 is called Bell, whereas in this forum thread (which I'd linked to from the page), you said that all the 1.x.y releases would be called Bell.

Also, I don't understand what this means: "Security releases are treated like minor releases or patches but might be released outside of the standard release schedule as required (e.g. in the middle of a month)." After all, the first table already states that patches are released as required, so why distinguish between a release schedule for patches and a release schedule for security releases? Surely a patch that isn't security-related would never get priority over a security-related patch. (At least, I hope not!)

Hope you'll clarify :)

Thanks,

Sam

Sam,

Sorry, you are too quick for me...

The version for 1.1.0 includes the Bell title. It was named at a time where it wasn't yet decided how we name releases. And I personally would keep it to include the name into new major releases (of which 1.1.0 was the first for the 1.x.y "branch").

Also, I don't understand what this means: "Security releases are treated like minor releases or patches but might be released outside of the standard release schedule as required (e.g. in the middle of a month)." After all, the first table already states that patches are released as required, so why distinguish between a release schedule for patches and a release schedule for security releases? Surely a patch that isn't security-related would never get priority over a security-related patch. (At least, I hope not!)

I'd like to fully explain how we treat security patches. Normally, we will not do patch releases, as the monthly schedule for minor releases is already rather fast. So I'd like to make it clear that we will release security fixes immediately and not according to some fixed schedule as it is done by many large corporations recently.

--Holger

Holger Just wrote:

The version for 1.1.0 includes the Bell title. It was named at a time where it wasn't yet decided how we name releases. And I personally would keep it to include the name into new major releases (of which 1.1.0 was the first for the 1.x.y "branch").

Understood, and I agree about the naming.

The trouble is, the way the article stands now, it reads as though 1.1.0 is called Bell and 1.2.0 doesn't have a name, but on the other hand version 1 is also called Bell. It's confusing.

Is there anything wrong with the way I had it in my last edit to the article? To me, at least, my exposition was clearer :)

Also, I don't understand what this means: "Security releases are treated like minor releases or patches but might be released outside of the standard release schedule as required (e.g. in the middle of a month)." After all, the first table already states that patches are released as required, so why distinguish between a release schedule for patches and a release schedule for security releases? Surely a patch that isn't security-related would never get priority over a security-related patch. (At least, I hope not!)

I'd like to fully explain how we treat security patches. Normally, we will not do patch releases, as the monthly schedule for minor releases is already rather fast. So I'd like to make it clear that we will release security fixes immediately and not according to some fixed schedule as it is done by many large corporations recently.

If that's the case, then I'm puzzled by your decision to change my text, which seems to me to capture that meaning precisely, and without the confusion caused by saying "security releases are treated like this or that but might be released like the other..." when in reality they're treated exactly the way the table states patch releases are treated: as required. Essentially, security patches are a subset of patches, right, regardless of whether they're a strict subset or not?

Also, since there's a general understanding that in the case of security patches, "as required" means "as soon as possible!", this reduces even further any need to try to separate security patches into a separate category with its own release schedule description.

I'm not trying to be competitive about this - I just find the wording in your latest edits to the article quite befuddling! Since my prior wording appears to capture the meaning that you've given to me here in this forum thread, would you be happy to revert the article to that wording?

Thanks again,

Sam

I added a short comment to the releases. This hopefully satisfies your naming definition issues...

Sam Kuper wrote:

Also, since there's a general understanding that in the case of security patches, "as required" means "as soon as possible!", this reduces even further any need to try to separate security patches into a separate category with its own release schedule description.

And exactly this is not the case. Security fixes don't necessarily mean "as fast as possible", but "when it done and safe". Also, as I said above, many vendors release security (and other fixes) according to some arbitrary fixed schedule. Which we don not do, what is the only thing I wanted to make clear. Also, even patch releases are most probably scheduled in advance (of only a week or two), while security patches are released without prior scheduling. That's why I wrote they "might be released outside of the standard release schedule".

Another thing to note is that it's also possible that security issues require enough changes to require a new minor version according to http://semver.org. They are not automatically simple patches.

--Holger

Holger Just wrote:

I added a short comment to the releases. This hopefully satisfies your naming definition issues...

Not really, it just makes things even more verbose :(

Isn't my version clearer and simpler?

Sam Kuper wrote:

Also, since there's a general understanding that in the case of security patches, "as required" means "as soon as possible!", this reduces even further any need to try to separate security patches into a separate category with its own release schedule description.

And exactly this is not the case. Security fixes don't necessarily mean "as fast as possible", but "when it done and safe".

There's not necessarily a contradiction between those two.

"As soon as possible" implies that there are constraints, otherwise one would just say, "immediately". In the case of security patches for stable releases, those constraints are pretty obvious: the patch must be believed to make things better, not worse. Specifically, it must be believed (preferably on the basis of evidence including tests) to ameliorate the security concern in response to which it was created, without causing undue impacts elsewhere. Once the security concern has been discovered, every available developer should be working to get the patch that state as soon as possible, at which point the patch will be done and safe (as far as is known) to release.

Also, as I said above, many vendors release security (and other fixes) according to some arbitrary fixed schedule. Which we don not do, what is the only thing I wanted to make clear.

Perhaps, but I'm afraid the current wording doesn't make it clear at all.

If you're:

1. concerned about visitors to the article arriving with the preconception that ChiliProject security releases will be made according to an arbitrary fixed schedule because that's what some other vendors do, and
2. convinced that even after reading that patches are released as needed, visitors will still hold this misapprehension,

then you probably need to say something like, "Some software vendors release security patches according to a fixed schedule. We don't. We release them as soon as possible." (I refer you again to my comment above about the meaning of the latter phrase.)

I don't, personally, think number 2 is a concern.

Also, even patch releases are most probably scheduled in advance (of only a week or two), while security patches are released without prior scheduling. That's why I wrote they "might be released outside of the standard release schedule".

Well, this isn't clear either.

In the table, you've written that patches will be released as needed, and yet here you're saying that they follow a standard release schedule sufficiently closely that security patches that are released as needed must be distinguished from them in terms of release schedule.

In other words, you seem to be saying that "as needed" ≠ "as needed". Confusing indeed!

Another thing to note is that it's also possible that security issues require enough changes to require a new minor version according to http://semver.org. They are not automatically simple patches.

Interesting point. Is it really possible for a security fix to require a backwards-compatible change to the API? (Or even a backwards-incompatible change to the API?)

If so, then insisting minor releases only happen once a month isn't such a good idea, because choosing between breaking a release cycle convention or leaving a security hole present for, say, a few weeks even though a fix has been written, just because that fix alters the API, isn't a nice choice to have to make.

There's another point to consider on this front, too: if, as you say, security fixes aren't always "patches" in the Semantic Versioning sense of the word, then it does make sense to distinguish them from patches. It probably also makes sense to mention Semantic Versioning right at the top of the article - in the very first sentence - rather than elsewhere.

Here's my proposed revision to the article, taking all this into account. What do you think?

Release Schedule¶

ChiliProject uses Semantic Versioning to help make our release version numbering comprehensible. The Semantic Versioning spec defines, among other things, what is meant by the terms "major", "minor" and "patch".

ChiliProject has a release schedule as follows.

Major release	roughly every 6 months
Minor release	roughly every month
Patch release	as required

Security fixes will be assessed as requiring major, minor or patch releases according to the Semantic Versioning spec, and will then incorporated into one of the above kinds of release as soon as can safely be managed, even if this requires a minor or major release to occur sooner than planned.

Future releases¶

For detailed and up-to-date information about planned releases please refer to the roadmap.

Past releases¶

Existing releases and their release dates are listed here.

Release names¶

Major versions are named. So far, we have:

Major version	Name
1.x.x	Bell