Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#26 closed enhancement (done)

Implement upgrading functionality for plugins

Reported by: swagner Owned by: swagner
Priority: medium Milestone: HeuristicLab 3.3.0
Component: ZZZ OBSOLETE: PluginInfrastructure.GUI Version: 3.0
Keywords: Cc:

Description

Enable upgrading of already installed plugins in the Pluginmanager Console.

Change History (15)

comment:1 follow-up: Changed 13 years ago by 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 ...

comment:2 in reply to: ↑ 1 ; follow-up: Changed 13 years ago by 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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 13 years ago by 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?

comment:4 in reply to: ↑ 3 Changed 13 years ago by 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?

comment:5 Changed 13 years ago by 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?

comment:6 Changed 13 years ago by swagner

  • Owner changed from gkronber to swagner
  • Status changed from new to assigned

comment:7 Changed 13 years ago by swagner

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

comment:8 Changed 13 years ago by swagner

  • Owner changed from swagner to gkronber
  • Status changed from assigned to new

comment:9 follow-up: Changed 13 years ago by 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?

comment:10 in reply to: ↑ 9 Changed 13 years ago by 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.

comment:11 Changed 13 years ago by swagner

  • Owner changed from gkronber to swagner
  • Status changed from new to assigned

comment:12 Changed 13 years ago by swagner

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed with r30.

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

comment:13 Changed 12 years ago by swagner

  • Milestone changed from 3.0 to Iteration 0

Milestone 3.0 deleted

comment:14 Changed 10 years ago by swagner

  • Milestone changed from Iteration 0 to Current

Milestone Iteration 0 deleted

comment:11 Changed 10 years ago by swagner

  • Milestone changed from Current to HeuristicLab 3.3.0

Milestone Current deleted

Note: See TracTickets for help on using tickets.