Implement upgrading functionality for plugins

[swagner]

Enable upgrading of already installed plugins in the Pluginmanager Console.

[swagner]

We should discuss one question: How to identify if a newer version of a plugin is available? Using only the version number is a little bit uncomfortable as we would have to increment it after every small change. Perhaps we should use some time stamps as well ...

[gkronber]

Replying to swagner:

We should discuss one question: How to identify if a newer version of a plugin is available? Using only the version number is a little bit uncomfortable as we would have to increment it after every small change. Perhaps we should use some time stamps as well ...

I think that it is actually a good idea to use the version string to distinguish between different plugin versions. Of course it is a bit awkward to change the build-number whenever we release a newer version of an plugin but this is also necessary when we use some kind of time-stamp.

When we use build-numbers there is also the benefit that we have a link between a given plugin version and the revision in the source repository. This wouldn't be the case if we only change a time-stamp in the XML on the update repository.

[gkronber]

Replying to gkronber:

Replying to swagner:

We should discuss one question: How to identify if a newer version of a plugin is available? Using only the version number is a little bit uncomfortable as we would have to increment it after every small change. Perhaps we should use some time stamps as well ...

I think that it is actually a good idea to use the version string to distinguish between different plugin versions. Of course it is a bit awkward to change the build-number whenever we release a newer version of an plugin but this is also necessary when we use some kind of time-stamp.

When we use build-numbers there is also the benefit that we have a link between a given plugin version and the revision in the source repository. This wouldn't be the case if we only change a time-stamp in the XML on the update repository.

One question however remains. Should we use the svn revision in the build-number of the version-number or is it better to just use a simple incremental scheme?

[swagner]

Replying to gkronber:

One question however remains. Should we use the svn revision in the build-number of the version-number or is it better to just use a simple incremental scheme?

Ok, let's use a build number for each plugin version. If we do so, I recommend to use the svn revision number. So we won't get confused with two different kinds of version numbers. However, it would be very convenient to update the version string automatically (i.e. patch the AssemblyInfo.cs) with each new revision. I think, there should be a possibility for that using svn properties. Anybody some experiences with that?

[swagner]

I found a way for automatically updating the version string in AssemblyInfo.cs using the tool SubWCRev (comes with TortoiseSVN). Executing SubWCRev in a pre-build event replaces a placeholder ($WCREV$) in a file with the highest revision number of a path in the working copy. As an example, please take a look at the project of the HeuristicLab.Core plugin.

Comments?

[swagner]

Modified project of HeuristicLab.Core as an example in r25.

[swagner]

By the way, shall we use the svn revision number as the revision or the build number in the version string? I would recommend using it as the build number. Otherwise, we would have quite strange version strings like 3.0.22.0. What do you think?

[gkronber]

Replying to swagner:

By the way, shall we use the svn revision number as the revision or the build number in the version string? I would recommend using it as the build number. Otherwise, we would have quite strange version strings like 3.0.22.0. What do you think?

I think the best is to use the current subversion revision as the build number.

[swagner]

Fixed with r30.

Automatically generated the version string in all projects using a pre-build event and the SVN tool SubWCRev.

[swagner]

Milestone 3.0 deleted

[swagner]

Milestone Iteration 0 deleted

[swagner]

Milestone Current deleted