This project is read-only.

Migrations and Module version numbers

Topics: Writing modules
Nov 2, 2012 at 10:50 AM

Hi Folks,

I was wondering how people handle versions of Orchard modules. At the moment we take the following approach

  • The module version (in modules.txt) is always set to match the migrations latest return number (e.g - if you have an "upgrade from 2" method, our module version is 3
  • developers use as many methods in migrations as required during a sprint (UpgradeFrom3, 4,5,6...) until the end of the sprint. 
  • At the end of the sprint, we "crush" these migration methods down to one higher than the last sprint release (e.g. if we released version 2 of a module the previous sprint, we will move all new changes in the migration into UpgradeFrom2())


We find that this a) allows migrations to work correctly for a developer exploring a changes/new widgets, b) allows for less overall code in the migrations section (as sometimes you write migration code to "undo" stuff you didn't like)

How do others work when versioning

I have been thinking also - would it not make sense to (somehow) link the migrations versions with module versions? This might assist the management of versioning?

Nov 2, 2012 at 8:27 PM
Edited Nov 2, 2012 at 8:28 PM

Interesting. But what do you do when you have multiple migration classes? And what about updates in your code for which no new migration steps are required?

Personally I just increase the revision component of the version number whenever I do some small updates. If there are new features, I increase the minor component. If it's a big enough feature, and or includes breaking changes, and or is specifically targeting a newer version of Orchard, I increase the major component.

Nov 2, 2012 at 10:59 PM

yeah - I didn't say it was perfect :) I think once we have our build server set up for it, we will just use it to update the module.txt files for our modules - we have several to keep in sync. From what you suggest - can you have multiple migrations files in a single module (for some reason never thought of trying this)? As to when no migration steps are required., I think we would just add an empty method (bar the return integer)

We are still playing with ideas - so it is nice to have feedback

Nov 3, 2012 at 12:29 AM

I know - I was just saying ;)

Absolutely, you can have multiple migrations. This can be useful if your module exposes multiple features and you bind your migration classes to each feature.

Well you don't have to actually add empty methods of course, as you could easily return the desired version number from the Create method.