> > Topic (new)

2006-09-29 - we should release v0.07 as stable

Sep 29, 2006 / pixtur
Jan 5, 2009 / phsouzacruz

Attached files

No files uploaded
As you might have noticed, I started restructuring the roadmap to v0.1. I've got the feeling that currently we have a little bit too many open construction sites and a too low stable release frequency.

I would like all developers to hold on for some days with starting new stuff and completely finish the v0.07 release.

As madlyr pointed out, we need to complete most of the translations. I will create accounts for all translators and drop them a mail.

Then we should assemble a v0.069 release, upload it at sourcefore and test it on all platforms.

Any other ideas on this topic?


tino:Yes, you're completely right!

12 years ago

So let's go for it!

pixtur:Are there any tasks we need to complete for this release?

12 years ago

tino:Reply to Are there any tasks we need to complete for this release?

12 years ago

I don't think so.

By all means I think we have all tasks done for the new stable release.
And the changes in comparison with the 0.065 release are really great.

binder:Reply to Are there any tasks we need to complete for this release?

12 years ago (3. update 12 years ago)

currently we're working on the task. It's working locally for creating a new task as notice, but lacks some functionality. we could release it after 0.07... especially as burger is on holiday next week. ;)

tino:Do you need any help?

12 years ago

Hey Tom, if you need help don't hesitate to ask.

binder:Antwort auf Do you need any help?

12 years ago

all tasks for 0.069 are done? 0.07 doesn't have any... are there any problems?


12 years ago

sorry. I have been inprecise on cleaning up the milestones. Thanks for reminding me. The current state is, that I have most of the updated translations ready. Maybe I can go through the release steps with barlas so I can do parts of this job.

pixtur:Discussing release cycles...

12 years ago (3. update 12 years ago)

Debian comes in three major branches, Stable (long release cycle, in the years), Testing (the new stable, a moving target really) and Unstable (an even faster moving target). For those who want to be as up to date as possible, the testing and unstable releases are useful as they continue to be updated constantly with packages moving from unstable to testing slowly (and then an even slower hop from testing to stable every time a release is made). The enthusiast could be viewed as the one following the unstable release (I admit my desktop is Debian Unstable) and always wanting the most up to date releases. I don’t think I could be a developer without have some small part of that desire inside of me, to get something and build it into a great product (Joomla!). In this, I am often faced with two issues: do I develop in 1.5 or 1.0.x? If the project needs to be running within the next week/month, it will have to be 1.0.x compatible. If the timeline is far more flexible, then I typically aim to a 1.5 application.

from Joomla

The project is a meritocracy — the more work you have done, the more you will be allowed to do. The group founders set the original rules, but they can be changed by vote of the active PMC members. There is a group of people who have logins on our server and access to the source code repositories. Everyone has read-only access to the repositories. Changes to the code are proposed on the mailing list and usually voted on by active members — three +1 ('yes' votes) and no -1 ('no' votes, or vetoes) are needed to commit a code change during a release cycle; docs are usually committed first and then changed as needed, with conflicts resolved by majority vote.

from apache

I would suggest following release stagesπ

Head revisions - v0.069.rev190π

Updates to the repository are only distinguished through their revision number.

Head releases - v0.069xxπ

Internal releases necessary for upgrading database or infrastructure

Releases Candiates - v0.07xRCπ

Before uploading a release to sourceforge or freshmeat, it needs to be tested for some days. This part it crucial and I always have minor problems with this step. Normally a release candidate should turn into a Release after two or three days.

Development releases - 0.07xπ

  • Comming out every few weeks
  • Should be production stable for advanced users (like streber.pixtur.de) will run this version
  • Are releases at sourceforge and freshmeat

Stable releases - 0.07π

Stable versions should be out every few months. (It have been 4-6 months or more for v0.05 and v0.06). Maybe we could increase this frequency up to 3 months. Having rough release dates (like first of Januar, April, Juni and September) could help?
Although I am not firm with SVN it might be useful to invest some research into forking the repository for stable versions.

Updated stable versions v0.0701π

Important bug fixes can be applied to updated stable releases like v0.0701. Maybe a developer can take responsibility for this step. We probably need release candidates for those updates as well.

Additional reading:

tino:Reply to Discussing release cycles...

12 years ago (3. update 12 years ago)

This brings us to

pixtur:Reply to Version numbers example

12 years ago (2. update 12 years ago)

Although this version numbering would be cool, it has some problems:
  1. streber sorts milestones for names (which would not work for versions like "1.10.2" and "1.2.23")
  2. streber compares the versions by string-compare to check for database updates ala, if "0.0234 < 0.0232" then to upgrade
Of cause both arguments are a faults with streber. The second problem could easiy be solved by a compareVersion() function. But the sorting of versions with sql causes me some headache.

madlyr:Reply to Reply to Version numbers example

12 years ago

use: 1.02.23, not 1.2.23 ;-), it will sort properly with 1.10.02 :-)
just use maskk xx.xx.xx, or x.xx.xx