User Documenta... > News / Updates > Topic (new)

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

New topicBookmark
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?

11 Comments

tino

Sep 29, 2006
Yes, you're completely right!
So let's go for it!

pixtur

Sep 29, 2006
Are there any tasks we need to complete for this release?

tino

Sep 29, 2006
Reply to Are there any tasks we need to complete for this release?
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

Sep 30, 2006
version 3
Reply to Are there any tasks we need to complete for this release?
currently we're working on the notice on persons? 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

Oct 11, 2006
Do you need any help?
Hey Tom, if you need help don't hesitate to ask.

binder

Oct 11, 2006
Antwort auf Do you need any help?
all tasks for 0.069 are done? 0.07 doesn't have any... are there any problems?

pixtur

Oct 12, 2006
Ups...
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

Oct 12, 2006
version 3
Discussing release cycles...


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

Oct 13, 2006
version 3
Reply to Discussing release cycles...
This brings us to restructure the team

pixtur

Oct 13, 2006
version 2
Reply to Version numbers example
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

Oct 16, 2006
Reply to Reply to Version numbers example
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

 
 

Comment / Update