Support next build number == 0 / zero

Pure Krome's Avatar

Pure Krome

05 Jul, 2015 12:12 PM

Hi Feodor,

hear me out on this crazy idea for a sec... :)

I hoping we could reset the Next Build Number == 0 / zero. Right now, it has to be 1 or greater.

The rational is this: `version: '1.{build}.0'

So, when I'm ready to create a master build of my library, i want to start out at 1.0.0. And any other releases will be 1.1.0, 1.2.0 etc.

If the api changes, then i need to manually bump the version to 2.0.0 (which means version: '2.{build}.0' <-- only the 1 is manually changed to 2). I'll reset the Next Build Number back to zero, merge dev -> master .. and my master CI kicks off, builds, packages then deploys for me.

Or .. is there a better way?


UPDATE: Also, Pull Request tests from GitHub also increment the build number.
So when I merge from dev -> master .. GH does a check to see if this code will work, right .. it does the entire CI except any deployment (yay! this is a nice merge-test...). When it's ok .. i then manually click the merge button and boom! CI fires off again .. but the build number is again incremented :(

This messes up my versioning for nuget packages if I wanted to do this auto-magically ...
I would love the option to not increase the build number for PR-tests.

  1. Support Staff 1 Posted by Feodor Fitsner on 05 Jul, 2015 08:35 PM

    Feodor Fitsner's Avatar

    Yeah, it's like two problems in this post :) Allowing 0 for next build number is doable - I filed a new issue:

    Seems like you don't necessary need to derive your version from from AppVeyor's build number. You can maintain version in AssemblyInfo.cs and if you need it in build context you can use a simple PowerShell script:

    Then using update version API you can update build version to something like %my_version%-(%appveyor_build_number%)

  2. 2 Posted by Pure Krome on 08 Jul, 2015 12:37 AM

    Pure Krome's Avatar

    You can maintain version in AssemblyInfo.cs

    I was basically hoping to avoid doing this for most builds ... except when it's for a major version change (following sem-ver).

    Remember, this is when we do builds for production .. so this means we PR from dev -> master and the AV project kicks off (branch -> only: master).

    So for most of the time it's not a major version. (think => this is for nuget repo's and our own website repo's).

    so in effect, this is changing the b in a.b.c.d semver.

    so this means -> we don't want to remember to touch/bump the AssemblyInfo.cs file when we need to do a release 95% of the time.

    for the remaining 5% - it's the rare occasion of a major semver change .. which means:

    1. we reset build counter to zero.
    2. we update the appveyor.yml from version: '2.{build}.0' toversion: '3.{build}.0'`

    unless, i misunderstood what you're saying :blush:

  3. Support Staff 3 Posted by Feodor Fitsner on 08 Jul, 2015 12:53 AM

    Feodor Fitsner's Avatar

    OK, I see. Then for now we are going to 0 in next build number.

  4. Support Staff 4 Posted by Feodor Fitsner on 14 Jul, 2015 03:38 AM

    Feodor Fitsner's Avatar

    It's been deployed.

  5. 5 Posted by Pure Krome on 14 Jul, 2015 04:06 AM

    Pure Krome's Avatar

    H U G

  6. Pure Krome closed this discussion on 14 Jul, 2015 04:07 AM.

  7. Pure Krome re-opened this discussion on 14 Jul, 2015 04:07 AM

  8. Pure Krome closed this discussion on 14 Jul, 2015 04:07 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac