Redmine

Yes, the version numbers are getting changed in the specific branches so trunk is still at 0.8.0. Jean-Philippe, should the release process bump the version number in trunk before merging the changes to the release branch?

The version number in trunk should be fixed indeed.
But I'm not sure it should be the same as the last release number. Currently, trunk is much different than the 0.8.3 release. Should we set something else like 0.8.9.devel or even 0.9.0.devel ?

anything other then 0.8.0 works for me :D
Perhaps it's a good idea to give it the versionnumber of the first next version on the roadmap?

Jean-Philippe Lang wrote:

The version number in trunk should be fixed indeed.
But I'm not sure it should be the same as the last release number. Currently, trunk is much different than the 0.8.3 release. Should we set something else like 0.8.9.devel or even 0.9.0.devel ?

I'd say to use the current stable version (0.8.3 now) since it includes the 'devel' BRANCH. Then a plugin could requires_redmine :version_or_higher => '0.8.3' to want 0.8.3 or trunk.

Eric Davis wrote:

I'd say to use the current stable version (0.8.3 now) since it includes the 'devel' BRANCH. Then a plugin could requires_redmine :version_or_higher => '0.8.3' to want 0.8.3 or trunk.

Agree.. Any idea when this will be fixed?? Since this is now also reported in the issuetrackers of some plugins (like [[http://github.com/mszczytowski/redmine_charts/issues#issue/6]])

Normally I would suggest, that the trunk is always high with numbers, i.e.:

• Last released version: 0.8.3.[1..8].x - usually you won't go further than 3-5
• Last development version: 0.8.3.9.x

This works for me event in the most complex projects, so it should work here as well...