Here is a copy of an IRC discussion between myself and giallu:

vboctor> I'm thinking about implementing a way to get the latest version of a project.
<vboctor> This can be used by Mantis to notify the admin of updates.
<vboctor> As well as applications that are managed by Mantis, can query Mantis for latest version.
<vboctor> For example, it would be something like:
<vboctor> http://www.example.com/mantis/latest_version.php?project_name=xyz&project_verison=1.1.0
<vboctor> This will return 1.1.1
<vboctor> The idea is for the manager of the project to define the rules. For example:
<vboctor> 0. -> 1.1.1, 1.0. -> 1.1.1, 1.1. -> 1.1.1, 1.2. -> 1.2.0a1
<giallu> ehehe this last feature is "funny"
<giallu> in a sense
<vboctor> or using the branch as an input. i.e. project_branch=dev
<vboctor> why funny?
<giallu> becuase the RPM guys have a whole pile of obscure code to deal with the fantasyt of developers when it come to versioning
<vboctor> if we use branch, then dev => 1.2.0a1 (or nothing), stable => 1.1.1
<vboctor> what does that mean?
<giallu> you know, rpm has to decide if version A > version B
<giallu> so it knows if you are upgrading
<vboctor> and?
<giallu> now, there are a bunch of projects out there
<giallu> and they are all using all sort of weird versioning numbers
<giallu> so it's a bet to get all them sorted properly
<giallu> see for instance perl
<giallu> or latex
<vboctor> I was thinking that the manager will define the rules.
<giallu> or add your name here
<giallu> yeah sorry, just digressing...
<vboctor> The important thing is for this feature to be available for any project using Mantis as a bug tracker, including Mantis itself.
<vboctor> since it is self hosted.
<giallu> yes. just one question
<giallu> isn't that something we can just expose in the SOAP api?
<vboctor> The trick bit is to come up with a format that is concise and easy for managers to keep up to date as they release new versions.
<vboctor> The problem is two parts:
<vboctor> 1. The log and the manager input format.
<vboctor> 2. How to expose it? i.e. soap or RESTful.
<vboctor> I think we should probably expose it in both soap / restful
<vboctor> this is to avoid introducing a dependency on SOAP for web projects that don't use soap.
<giallu> ok
<vboctor> they can do a file_get_contents( $t_url ) to get the version.
<vboctor> or use curl
<vboctor> any ideas about how the admin would define the rules?
<vboctor> I was thinking of a free text field associated with the project.
<giallu> then we parse it? looks sensible
<vboctor> but it can also be a field on the version table as long as we provide a GUI that allows quick editing.
<giallu> yeah
<giallu> the other option could be
<giallu> use the order the admin entered the versions in manage project
<giallu> of of course provide a way to edit it
<vboctor> we can add a "branch" field to the version. Then return the latest released for a branch.
<giallu> yeah
<vboctor> however, it would be tricky to handle the transition from "dev" to "stable".
<vboctor> 1.0.0rc3 -> 1.0.0
<vboctor> The other option is for each version to have a successor field, then follow the chain from the user's versions to the latest (latest doesn't have a successor).
<giallu> they are on different branch, you should't compare them...
<vboctor> We should, if the user has the latest rc and then we released stable, then we should recommend the upgrade to the stable version.
<giallu> successor concept basically seems to fall back to the ordering on the manage project page
<vboctor> Not really. Since the order in the project page will have the dev / stable branch versions mixed.
<vboctor> successors will not mix unless a stable release follows a dev release.
<vboctor> So if user has 1.0.0 and latest is 1.0.8, then the chain will work as follows:
<vboctor> 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.0.4 -> 1.0.5 -> 1.0.6 -> 1.0.7 -> 1.0.8
<vboctor> If user has 1.0.0a1, then the chain will be:
<vboctor> 1.0.0a1 -> 1.0.0a2 -> 1.0.0a3 -> 1.0.0a4 -> 1.0.0rc1 -> 1.0.0rc2 -> 1.0.0rc3 -> 1.1.0
<vboctor> 1.0.0a1 -> 1.0.0a2 -> 1.0.0a3 -> 1.0.0a4 -> 1.0.0rc1 -> 1.0.0rc2 -> 1.0.0rc3 -> 1.1.0 -> 1.1.1
<vboctor> Then we should display next to each version in the manage project version, what is the recommended upgrade for it.

• Orac (n=jb_buldo@082-146-097-038.dyn.adsl.xs4all.be) has joined #mantishelp
  <vboctor> So the admin can quickly find broken chains.
  <vboctor> although this would work, I have a feeling a free text field would make most sense for the users.
  <vboctor> 1.1. -> 1.1.1
  <vboctor> 1.2. -> 1.2.0a1
  <vboctor> 0.9. -> 1.1.1
  <vboctor> 0..* -> 1.1.1
  <vboctor> First rules that matches wins!
  <giallu> honestly... I think I will never touch that, too messy ;)
  <vboctor> so, what do you think is the best approach from the ones I mentioned so far?
  <vboctor> Do you have other recommendations?
  <giallu> I could... but I 'd need to think about it.
  <giallu> the tricky part
  <giallu> seems to be
  <giallu> the unstable->stable transition
  <vboctor> yes. We can handle this through: branch + latest time
  <vboctor> and handle the transition with a specific override.
  <vboctor> so the user has to enter a branch name per version.

The more I think about this issue the more I am convinced we should try to make it as simple as possible.
Surely, the Mantis user base (and in particular the admins/managers who are supposed to handle this) should know what are they doing, but I think a simpler approach should be a win in the run because it will generate less support requests.

That said, I'm leaning toward this approach:

on the administrative side, make a best guess about where a new version should land in the list of versions, but let the user shuffle the order as needed.

attach a new property to the versions (I'll name it "channel" hereby, but I'm sure you can find a better name)

Channels are ordered and works like the acl thresholds: higher channels can access lower channels

In our scenario, we have two channels: stable and development

so we could have something like:

|| version || channel ||
|| 1.2.0a1 || devel ||
|| 1.1.1 || stable ||
|| 1.1.0 || stable ||
|| 1.1.0rc2 || devel ||
|| 1.1.0rc1 || devel ||
|| 1.0.2 || stable ||
|| 1.0.1 || stable ||
|| 1.0.0 || stable ||

the query could be something like:
latest_version.php?project=xyz&current=1.1.0&channel=stable
returns 1.1.1

latest_version.php?project=xyz&current=1.1.0&channel=devel
returns 1.2.0a1

latest_version.php?project=xyz&current=1.1.0rc1&channel=stable
returns 1.1.1

sounds like a plan? ;)

Please explain the following statement in more details:
"Channels are ordered and works like the acl thresholds: higher channels can access lower channels"

Here are some more requirements that we should consider / misc. notes. Although they don't all have to be included in v1 of this feature, but we should keep them into consideration.

1. Cases where there are multiple flavors of a product: MyProduct Standard, MyProduct Pro, MyProduct Enterprise. Although probably in such case when a new release is available it is available for all flavors. But it is a scenario that should be taken into consideration.

2. When a new version is available, include some flags / comments like. Security bugs, etc. Or maybe a link to such information.

3. Link to change log.

4. The response returned by the server should be extensible, so that the server can return more information than what was available when the client was developed without breaking the client. Kind of like XML where adding a new element doesn't break clients that read the XML and don't know about the new element. XML is a possible format to use for that :), but other formats can be used which provide the same forward compatibility.

5. Should the client send through a protocol version? e.g. protocol=1. This will only need to change if the server returns a format that can break older clients and hence return the format based on the client version. The better job we do in 4, the less likely we need this. The other option is to have a new entry point (php script) when a new protocol is returned that is not backward compatible.

Channel: stable => ID: 10
Channel: development => ID: 20

the get_latest_version function should use a query returning versions with channel_id <= requested channel_id.

In my previous comment, I was just noting this concept is the same we use for ACLs, where we can check if the given user has an access level equal or greater than a reference.

I hope this is clearer. if not, ping me :)

couple of comments, how do you plan to deal with customizations outside of *_config files?
--Will you not perform the upgrade at all
--perform the upgrade, but provide a log to show which files have customizations and need to be merged manually.

I don't know much about mantis or Plone, but plone's buildout system is great for managing upgrades. Not sure if that is something you could use.