Home → Problems →

Different versioning and deployment per branch

• Edit

lair

02 Nov, 2014 10:53 AM

I have following (supposedly, very common) scenario. I am developing a NuGet package, and I want to separate CI and stable packages. Intended workflow is:

When somebody pushes a commit to master, AppVeyor

• picks it up, fires up a build
• sets version to [current version].{buildnumber}-ci
• builds, tests, assembles a .nuget
• pushes to nuget.org

When somebody pushes a commit to release, AppVeyor

• picks it up, fires up a build
• sets version to [version specified for release].{buildnumber}
• builds, tests, assembles a .nuget
• leaves it in artifact repository for manual deployment

In short, I'd like to be able to:

1. setup manual deployment for one branch and automatic deployment for another

   As far as I understand, that's already possible by using conditional deployment

2. setup different assembly versioning patterns for different branches

   As far as I understand, this could only be done with conditional build configuration, which could only be done in appveyor.yml and involves copying common setup for all branches.

3. build only the branch that triggered the build

   That, too, is possible by combining default branch/branch whitelisting, but to setup differently for each branch, it'd require appveyor.yml as specified above.

(...or of course it could all be done with two different build projects, but it, too, involves copying setup, and feels untidy)

Is there something you'd recommend me?

1. Support Staff 1 Posted by Feodor Fitsner on 03 Nov, 2014 09:48 PM

   

   In general, everything you described here is correct. You should give it a try and let me know if there any issues. Also, if you get an idea how configuration process for such scenario could be improved/simplified feel free to share your thoughts.

   • Edit

2. 2 Posted by lair on 04 Nov, 2014 03:51 PM

   

   I'll try using conditional build configuration, but here's what I think about simplifying my use-case scenario:

   1. There should be a simple checkbox "Build only the branch that was committed to"
      
   2. If that one is checked, there should be a possibility to specify build version format conditions (the way it's already done for deployment, or just branch name/regex)

   There's also another thing that I think could be helpful: the possibility to export current UI configuration as an appveyor.yml file.

   • Edit

3. 3 Posted by lair on 04 Nov, 2014 06:09 PM

   

   Oh, there seems to be a further problem. Build version format does not allow for postfixes (like 2.0.{build}-pre), so either it should be changed, or version conditioning should also apply to AssemblyInfo patching.

   • Edit

4. Support Staff 4 Posted by Feodor Fitsner on 04 Nov, 2014 06:41 PM

   

   Yeah, AssemblyVersion attribute doesn't accept semver format. Do you have an idea how to better deal with that?

   • Edit

5. 5 Posted by lair on 04 Nov, 2014 06:49 PM

   

   There's no way to deal with this (Microsoft works around that by using AssemblyInformationalVersion).

   And am I right that you can't allow pre- or postfixes in AppVeyor build version because you want it to be directly translatable to AssemblyVersion?

   And why does build version have to be unique (as stated in Build versioning)?

   • Edit

6. 6 Posted by lair on 04 Nov, 2014 09:09 PM

   

   I am sorry for not paying attention. Documentation says:

   When you do a push to the repository AppVeyor will start a new build of the branch in the last commit of the push data.

   Which means that AppVeyor behaves the way I wanted ("build only the branch that triggered the build") by default (and that's the only behaviour). So no change is required there; but the ability to specify different versioning patterns for different branches is still needed. I'll try to think about the easiest way to deal with that.

   • Edit

7. 7 Posted by lair on 05 Nov, 2014 11:23 AM

   

   I could see two different (and not mutually exclusive) solutions here.

   Option 1

   We could add a possibility to specify different build versions for different branches (e.g: release branch - 1.0.{build}, develop - 2.0.{build}, all the others - 1.5.{build}). There are, again, two options to solve the problem with semver:

   1. We could allow semver in build version, and strip all non-complian symbols before writing to AssemblyVersion and AssemblyFileVersion
      
   2. We could add another configuration option (something like "build version postfix"), that could be referenced from AssemblyInformationalVersion (something like {version}{postfix}, postfix being set up as empty for release and -ci for master)

   Option 2

   I just remembered that omnipresent comment from AssemblyInfo.cs:

   // you can default the Build and Revision Numbers  by using the '*' as shown below:
   [assembly: AssemblyVersion("1.0.*")]
   

   We could "teach" AppVeyor to replace * in AssemblyVersion and AssemblyInformationalVersion with build number (and we will have to replace AssemblyFileVersion with AssemblyVersion). This way we will get:

   • more or less consistent experience between VS and AppVeyor
   • less configuration in UI
   • version numbers in version control (which is helpful in several scenarios)
   • Edit

8. Support Staff 8 Posted by Feodor Fitsner on 13 Nov, 2014 04:58 AM

   

   Thanks for your thoughts!

   Just to summarize, I think the following is pretty doable in AV:
   1) Strip anything after dash from patch number to use within AssemblyVersion and AssemblyFileVersion attributes.
   2) If * is found in Assembly{something}Version attribute replace it with build number and do not use version template defined for the project.

   Will add a new item for that:

   • Edit

9. 9 Posted by lair on 13 Nov, 2014 08:20 AM

   

   Thanks a lot. Am I right that

   1. AppVeyor will allow build number templates containing postfixes?
      
   2. Different build number templates for different branches won't be available from interface, only from appveyor.yml?
   • Edit

10. Support Staff 10 Posted by Feodor Fitsner on 13 Nov, 2014 08:11 PM

    

    We'll change UI validation to accept postfixes and yes different branch version templates will be in YML only (and it's available even today).

    Frankly, UI wasn't designed around multi-branch configurations - this is bad and we are going to re-think it as some point.

    • Edit

11. 11 Posted by lair on 13 Nov, 2014 09:34 PM

    

    Thank you for the clarification!

    • Edit

12. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:50 AM.