Releases and updating version numbers

[jusjoken]

A few of us have been having a discussion through email/PM's around this topic so I thought we should get this open to the community.

One of the tasks I have had to do while building out the Windows Installers was to change the internal version numbers in a few locations prior to building the release and then the installer. This includes...

• Windows SageLauncher - change file version and product version in rc file
• Windows MiniLauncher - change file version and product version in rc file
• Windows Installerinclude - change product version AND installer version
• Sage.jar - I have never changed the base version on this myself so someone else will need to tell us how this is done

The manual process I have used in the past is....

• ask Stuckless to build the Sage.jar
• record the version number from the Sage.jar ie: 9.0.4.xxx
• update the 3 locations in the Windows development environment as stated above (note: until I commit the installer build code the last item so far needs to be done by me on my build machine)

I did it in the above order so the Sage.jar and Windows exe's would all have the identical version number.

Now...for the Windows installers it is key that if a developer commits new functions that they want the installer updated so users can perform an UPGRADE, then the 3rd digit in the version must be updated...ie: 9.0.3.xxx needs to become 9.0.4.yyy. For example the way the installer is set up is that 9.0.3.yyy will not install over 9.0.3.xxx as the installer sees this as the same "version". There are ways around this however it would then break the process for upgrading between V7 and V9 so I have tested that and prefer not to go there.

So my suggestion is....developers need to increment the version (3rd digit) when they commit changes that need a build of the Sage.jar or requiring a new windows installer to be created and released.

Comments welcome.

k

[EnterNoEscape]

I'm wondering if when you get your changes in for the Windows installer, we could add a task to gradle that would do all of the needed increments automatically and after running the task, all the developer would then need to do is commit the changes.

The gradle script refers to ./java/sage/Version.java for the major, minor and micro version. The build number is supposed to come from ./java/sage/SageConstants.java, but the gradle script appears to only use that number if you're not using Linux. That step could be adapted to do something similar on Windows. You just need to have git already installed and in the PATH environment variable which most people would already have if they are doing this kind of development. This is where the version used for Sage.jar is created.

[Fuzzy]

For now, and for the pace that commits are coming in (slow), I think a manual process is decent enough. Honestly, having the fewest number of people manipulating version numbers is probably for the best. The way I see it, a lot of the 'little' fixes (I'm getting set-up to do one now) don't need to be released right away, so simply committing them, and not ordering a new build, is probably fine. Things like EnterNoEscapes remuxer work, however, does warrant a new build, so that's when the micro version would be incremented, and ultimately, that's when a Changelog would be released, so we'd have a commit that did nothing but version updates - it would include number change in Version.jar, and the changes to the rc files, and an entry in a changelog file summarizing the work done since the last micro version change.

Minor Fix: Developer simply commits the change. This won't get distro'd until the next "Change".
Minor Change: Developer commits the change, and requests a new release from managers (jusjoken & Stuckless at this point). Manager increments version info and changelog, and checks this in as a separate 'version update to x.x.x' commit. Managers build the new version and upload to bintray.

I think this process would work. Alternatively, the individual developers could be responsible for adding notes to the ChangeLog, but I think that might be inconsistent, and things would get mixed. I also haven't discussed how Jeff works into this, because obviously there'd be delays waiting for his approval into the actual google/sagetv repository before the next steps could be finalized.

[EnterNoEscape]

You made some good points. The version updates/release notes updates should probably be limited to a small number of people ( <= 3) so we can keep things consistent.

I still think it would be nice to add a gradle task to help them out a little or we should find a way to get Visual Studio to take a cue from Version.java/SageConstants.java. Ideally these things shouldn't need to be changed in more than one place. I usually lean towards automation when it should mitigate human error.

[jusjoken]

Originally Posted by Fuzzy

Minor Fix: Developer simply commits the change. This won't get distro'd until the next "Change".
Minor Change: Developer commits the change, and requests a new release from managers (jusjoken & Stuckless at this point). Manager increments version info and changelog, and checks this in as a separate 'version update to x.x.x' commit. Managers build the new version and upload to bintray.

As I have not uploaded the installer code/solution then I obviously need to be involved for now....but do not want to have everyone depend on me for this long term....share the pain

However, I personally feel that the change owner should be responsible to create a change log and change the few manual locations where the version number needs changing as part of their change commit. This way when Jeff approves it then it is ready for the "managers" to pull, build and create the installer packages.

k

[jusjoken]

I have done some more reading on this topic and believe that when I find time and if someone else doesn't decide to do something else first I may be able to...

• use MSBUILD and perform the release build and the installer build from the commandline
• use MSBUILD to read in the MAJOR, MINOR and MICRO versions from Versions.java
• use MSBUILD to get the GIT count of commits to set the build number part of the version
• use MSBUILD to update the 3 windows resource files to the new version
• use MSBUILD to either call the Gradle script to build the JAR OR there may be ways to use Gradle to call MSBUILD as there is a gradle plugin for that....need to test this out
• use MSBUILD to build the release files
• use MSBUILD to compile and build the Setup files

I have never done anything in the past with MSBUILD but I found examples for each of the above so I may be able to accomplish these.


I have not searched yet but I may be able to clone the repo as part of the MSBUILD or Gradle scripts initially to help to automate more of the process but we will see if the above works first.


I will give this a try as time permits but others feel free to jump in and volunteer to take this on


However, I still feel that the developer that is commiting their functionality changes should update the version in Versions.java as part of their commit OR Jeff does this if he feels this is major enough when he merges the commits. Either way, I think the new version number needs to be already on GitHub in a committed state otherwise after the build/release I would need to push a change for the Version number..... but open for suggestions.


k

[Fuzzy]

Every compilation action that visual studio does, I believe, is done via MSBUILD, so it SHOULD be able to be built there. I thought somewhere Visual Studio even writes out a lot of all MSBUILD commands it used - or at least it did at some point - so yeah, it SHOULD be able to be built all from command line, which means all from Gradle - that really SHOULD be the ideal end case - a build system that takes the git, and outputs JUST the installer files for each platform we target - but of course, as I'm sure you're aware, that alone is a pretty extensive task to set up, and right now, you're the only one who's ever even built the windows things manually, let alone even look at automating it.. :-)