New Versioning Policy

[gOOvER]

(08-20-2009 05:59 PM)joximu Wrote:  Well, we saw several proftpd issues on lenny - but I could not check if the bug is in the software or at the keyboard...

Last Week i installed ispCP on 2 Debian Lenny Machines and i hadn't any Problems with ProFTPd. So i thinks it's on the Keyboard ;D

Quote:Or just release a patch (why risk a faulty update mechanism if a patch would be faster and easier).

Maybe we should think about an Autoupdate for such things

[BioALIEN]

How about we reserve odd version numbers for testing and betas for the community to test and even version numbers for official releases?

ispCP v1.0.1 = testing internally and for the community to carry out
ispCP v1.0.2 = the official release after the above tests are done
ispCP v1.0.3 = fix another bug/security issue and release to the community
ispCP v1.0.4 = if no problems with v1.0.3, retag and release officially.

ODD releases do not get official announcements, they are simply handled via the develoment forums and for beta testers.
EVEN releases get the full announcements as we currently do.

[gOOvER]

(08-20-2009 08:20 PM)BioALIEN Wrote:  ispCP v1.0.1 = testing internally and for the community to carry out
ispCP v1.0.2 = the official release after the above tests are done
ispCP v1.0.3 = fix another bug/security issue and release to the community
ispCP v1.0.4 = if no problems with v1.0.3, retag and release officially.

Better is: for a beta p.e. 1.0.1beta1,2,3 etc, before Release 1.0.1rc1,2,3, etc

[kilburn]

I don't like the "betaXX" or "rcYY" appends, they seem stupid to me. My three options would be:

1. Do as BioALIEN says, I like his idea.
2. Don't follow any convention about minor releases. The ones announced as stable are stables, the others aren't.
3. Append a "build" number, so "x.y.z" releases are the stable ones. "x.y.z-1.t" are betas/rc's. This way, we would release 1.0.1.xx (increasing xx) until 1.0.2 is ready, then 1.0.2.xx until 1.0.3 is ready, etc.)

[gOOvER]

For .xx we can use SVN Versions, like r1907

[joximu]

I also would not use "alpha"/"beta" etc... - the ispcp testers can live with one of the options killburn listed in Post 24.
Personally I'd like Variant 1 (from BioALIEN) or 3 with the svn-version appended (this can be appended also in the official releases... - so it's easy to get an official release out of the svn...

And it looks like we need branches in the development. An 1.0.x branch for the sec-updates for 1.0. And a 1.1 branch as soon as feature freeze has been reached - and of course the trunk which can be continued to the 1.2 etc...
Important fixes need to be implemented in several branches - but I think this will be a more clear handling.

/J

[RatS]

This is the first time we set up any policies. And of course they have to be developed. We need branches for bugfixes, never had this before and now I tried to do set it up. it's not working as it should so far, but improving.

[momo]

Quote:1. Do as BioALIEN says, I like his idea.
2. Don't follow any convention about minor releases. The ones announced as stable are stables, the others aren't.
3. Append a "build" number, so "x.y.z" releases are the stable ones. "x.y.z-1.t" are betas/rc's. This way, we would release 1.0.1.xx (increasing xx) until 1.0.2 is ready, then 1.0.2.xx until 1.0.3 is ready, etc.)

This sounds good.

By the way, why do you need to release a security patch for something that isn't ispCP core ?
Isn't it admins responsibility to patch security holes for this ?

[kilburn]

Squrirelmail is distributed with the ispcp's core, so it's our responsibility to release a new version when it has to be updated.

[monotek]

Sorry, but i dont like the idea of Bioalien.

People who dont know about this scheme would think that a 1.0.1, 1.0.2 or 1.0.3 are final releases.

This is not standard in open source projects. Why do you want to reinvent the wheel?

Just use 1.0.1 alpha, beta and rc like its done by most other projects too.

This would help a lot to keep development transparent. Otherwise people would only be worried...