Forum OpenACS Development: Up the version numbers !!!

Collapse
Posted by Malte Sussdorff on
This is a general reminder to all of us that we have to update the version number of a package if we make changes to it. This is especially true if:

- Change of datamodel
- Change of apm-callbacks
- Change of parameters

But as everyone using the package repository at openacs.org will not get the new changes if we do not update the version number, PLEASE up the version number with every commit you make (or at least every second one on the same package)

Thanks

Collapse
Posted by Rocael Hernández Rizzardini on
I though this was a task of the release manager, then, when he/she changes all the .info to the next version, all the upgrades will apply for the next official release ...

But if this is the right way to do it, np ;)

Collapse
Posted by Dave Bauer on
I think that the release manager should update the version numbers, although if you change something like add a parameter etc, it is helpful to change d1 to d2 or a similar update for developers who are tracking CVS.

You should always increase the version number in the info file before tagging a package for openacs-*-*-compat for example. This makes sure that users who install from the repository get the latest version.

As this is the case, I don't think you really need to increase the version on _every_ commit. Just when the code in a consistent state. So I think you need to use your judgement here.

Collapse
Posted by Jade Rubick on
The proposed guidelines for developers is here, at the bottom:

https://openacs.org/forums/message-view?message_id=192919

Collapse
Posted by Joel Aufrecht on
As release manager for OpenACS Core, I update the release numbers for the CORE PACKAGES ONLY. These are
acs-admin
acs-api-browser
acs-authentication
acs-automated-testing
acs-bootstrap-installer
acs-content-repository
acs-core-docs
acs-kernel
acs-lang
acs-mail
acs-messaging
acs-reference
acs-service-contract
acs-subsite
acs-tcl
acs-templating
ref-timezones
search
Tracy Adams updates the release numbers for the .LRN packages. All other packages are essentially updated and released by individual package developers. This may not be an ideal situation for developers who contribute a small fix at a time, because it requires them to do some testing and release work in order for their contributions to have effect. We are at this situation because:
  • Release management includes quality assurance. Nobody has volunteered to do quality assurance for over a hundred different packages
  • We have not been able to maintain a corps of package maintainers.