command line version bump

[joegaudet]

When running the build from external tools would be handy to have a version number bump that would allow us to verify that our client were on the current live version.

Ideally would bump the minor version number 1.2.x

[mauritslamers]

I am not entirely sure that I understand what you try to say here. Sorry also for seeing it this late, for some reason I must have missed it.

[dcporter]

Joe was hoping for an automated build counter somewhere. I'm not sure how this would work, and I don't think that doing anything in the x.x.x rubric is a good idea, but it would be nice to have an auto-incrementing build number somewhere.

For example, my mac is running OS X 10.8.2 build 12C60. I bet that 12C60 part is tracked automatically.

[mauritslamers]

There is a buildVersion property, which defaults to new Date().getTime() This could be overridden by a function of some sort, or a computed property.

For myself, I usually deploy using git, in which my build directory is a repository on its own. I only commit the stuff I want to commit and push that to my deploy repo.

From the deploy point I can easily and quickly get the latest changes, or revert back to old build versions if necessary.

On 23 okt. 2012, at 20:02, Dave Porter wrote:

Joe was hoping for an automated build counter somewhere. I'm not sure how this would work, and I don't think that doing anything in the x.x.x rubric is a good idea, but it would be nice to have an auto-incrementing build number somewhere.

For example, my mac is running OS X 10.8.2 build 12C60. I bet that 12C60 part is tracked automatically.

— Reply to this email directly or view it on GitHub.

[dcporter]

Is there any way for the build tools to store that kind of state from build to build, without storing it in (ergo modifying) the source code? "Bump my version" implies that it knows what the previous version was.

[mauritslamers]

Not at the moment, unless it is hardcoded in the build-tools config file. Of course it is very easy to achieve this by having a .buildNumber file in the project or build directory which stores it. This kind of behavior is very easy to add by adjusting the config file (which is currently still an executable) to set the build number to read from the file. The callback on save function can then be used to up the number.

Of course, this kind of thing only works with one developer working on a project. I wouldn't know a way to sync it, unless that build number file is included in the VCS, but that would require a commit and push for every build (and a pull everywhere else).

On 23 okt. 2012, at 21:59, Dave Porter wrote:

Is there any way for the build tools to store that kind of state from build to build, without storing it in (ergo modifying) the source code? "Bump my version" implies that it knows what the previous version was.

— Reply to this email directly or view it on GitHub.

[mauritslamers]

@dcporter abbot stores its versioning through the directory structure of the build, is that the kind of version information you are looking for? Or would automatically adding a VERSION file to a build be something?

[dcporter]

I don't need nothin, I'm just facilitating. =)

You're mentioning two very different things of course. I'll go on about them so everyone in the conversation is clear. I'm interested in the first, and @joegaudet (and hence this Issue) is interested in the second.

First: Abbot currently includes an MD5 (I assume) hash of a frameworks' contents in the framework's directory structure, in order to support aggressive caching. If a built file changes, then its hash will change, meaning that its URI will change, causing previously-cached versions to be dropped from use automatically. Since we're confident that new versions are at new URIs, we can reliably cache files "forever", improving application load performance substantially. It's very slick, and losing this feature would be a major regression for production performance. If this isn't available yet in garcon then let me know and I'll open an Issue!

This is unrelated to Joe's request though, which is for a proper human-readable version management system, for example bumping from 1.2.2 to 1.2.3 on build, presumably in a VERSION file somewhere. It's my view that automating this would be a bad idea, since the version number semantics are so fluid and aimed at humans anyway. Joe, thoughts?

[mauritslamers]

About first: So this is the reason why the URIs of Abbot are so needlessly complicated ;-) This functionality is definitely not present in garcon. I expect though that it should be pretty easy to add though, especially if it only needs to be present in saving mode. How much time it would take depends on what exactly is calculated through the MD5. For example, currently the combined sproutcore scripts are put in a single file, as well as the css, which both reside in the root of the application. There is a app.js, an app.css, an app_sc.js and an app_sc.css. This is done to allow builds of different sproutcore versions in the same process. The images though are stored in a directory structure. I would love to have some input on how the end build should look like for maximum deploy convenience. We might even include a few (configurable) strategies depending on different situations.

About second: this is also very easy to add, because with garcon it is possible to make a custom buildVersion per application by overriding the default value. So, if this would be needed, the buildVersion computed property can both read and write its version in a different file if needed.

[dcporter]

Sounds like handling Joe's needs are straightforward. I'll open a new issue for the MD5 question.

[publickeating]

RE: versioning. It would be great if the "build" number were incremented automatically, which could be appended to the manually maintained version. This would make it much easier to communicate with your QA group about which build to test. For example, if I set the version of my app to 1.1.0, after 23 builds, MyApp.Version would return "1.1.0.23". If you look at OS 10.8's Version it is actually 10.8.2.12C60 (Xcode would be incrementing 12C60 for them). The build number could be stored in a hidden file within the app folder, maybe a .sproutcore JSON file would be useful.

RE: paths. Like Dave details, "versioned" resources are absolutely essential. I was scolded early on by Charles when I wanted to override the automatically generated build path using "--build=current". I believe the current way that Abbot does this might be the best approach, but I don't have much experience with server deployments. Check out rules 2, 3 & 13 here: http://blog.sproutcore.com/how-sproutcore-makes-your-app-run-faster/

[mauritslamers]

I feel that this versioning needs to be flexible and configurable, so I propose to use something like similar like sc_static or sc_require, perhaps sc_version() that will allow the build tools to insert a version in a specific file of choice. The way this versioning works could then be configurable, say versionScheme: "1.2.x" and the x would then be replaced by an automatically chosen number, which would again be configurable by overriding the standard function.

One of the things that is much easier with the new build-tools is create builds with relative paths. I found that in this case I might also introduce something like sc_deployurlprefix(), as the XHR urls need to be adjustable with regards to the actual deployment. This can make life much easier for many different types of app deployment.

I had a look at both the blog post and the linked deployment guide and to me this way of deploying feels very much like a "one size fits all" strategy. I am currently deploying a CouchApp, and in this case having all the different MD5 hashes would make things more complicated. So I would rather cater a few different configurable approaches, which shouldn't be very hard to do.

@publickeating as you seem to be much more familiar with abbot, what is the mechanism exactly? Is this a MD5 based on the contents of the framework? I have tried to find it, but it is quite easy to get lost in the source.

[publickeating]

I don't know how Abbot does it, only that the resulting paths are important. A cool thing with the hash is that you can clone an app onto a completely different computer, do a build and get the same versioned URIs.

Also, just to be clear I don't think anyone should be asking for automatic version "naming". Only automatic build numbering. You cannot actually auto-increment a version name, because they are and should always be Strings. This is why I had to rewrite SC.browser.compare, because it was assuming that all versions were equivalent series of numbers and thus failing miserably*. Think version names like "0.9beta", "2013-01-24patch2" or "slippery-fish.nightly". The actual version name is dependent on the developer, so simply changing MyApp.VERSION in core.js is sufficient. That's not to say that version naming schemes aren't good to have, only that I don't believe there is any benefit in making them programmatic.

However, the build number is definitely something that the build tools could increment automatically. I've just used Visual Studio for a Win8 SproutCore app and it does exactly that and I'm pretty sure Xcode behaves the same way. Each compile increments the build number, which can be appended to the user supplied version string to ensure that QA and Dev are talking about the same build (ex. MyApp.VERSION + "_build" + SC.BUILD_NUMBER == "iphone,1.1.5_build12").

I can see at least one flaw with automatic build numbering, but it's the same flaw shared by all IDEs in a team environment. The build number file must be committed into the repository or else multiple developers working on the same code will have inconsistent build numbers. Usually only one computer does the actual building, so this may never catch anyone, but it would definitely have to be documented.

Just to keep our context straight, I think we should try to use "Version Name" (ex. "1.3.0rc1"), "Build Number" (37,38,39...) and "Versioned URIs" ("/images/some_hash/bg.png").

Thanks,

Tyler Keating tyler@sproutcore.com

• Not that the improved SC.browser.compareVersion is infallible, but it at least has a better chance of getting it right when version strings look like a series of integers. I'm pretty sure I've written in the docs that I don't recommend using SC.browser for anything more than as a last result.

On 2013-01-14, at 2:18 AM, Maurits Lamers notifications@github.com wrote:

I feel that this versioning needs to be flexible and configurable, so I propose to use something like similar like sc_static or sc_require, perhaps sc_version() that will allow the build tools to insert a version in a specific file of choice. The way this versioning works could then be configurable, say versionScheme: "1.2.x" and the x would then be replaced by an automatically chosen number, which would again be configurable by overriding the standard function.

One of the things that is much easier with the new build-tools is create builds with relative paths. I found that in this case I might also introduce something like sc_deployurlprefix(), as the XHR urls need to be adjustable with regards to the actual deployment. This can make life much easier for many different types of app deployment.

I had a look at both the blog post and the linked deployment guide and to me this way of deploying feels very much like a "one size fits all" strategy. I am currently deploying a CouchApp, and in this case having all the different MD5 hashes would make things more complicated. So I would rather cater a few different configurable approaches, which shouldn't be very hard to do.

@publickeating as you seem to be much more familiar with abbot, what is the mechanism exactly? Is this a MD5 based on the contents of the framework? I have tried to find it, but it is quite easy to get lost in the source.

— Reply to this email directly or view it on GitHub.

[joegaudet]

Yeah this makes sense to me.

Currently we've just been appending the github revision hash to that string, which is less than ideal.

.joe On 2013-01-14, at 8:06 AM, Public Keating notifications@github.com wrote:

I don't know how Abbot does it, only that the resulting paths are important. A cool thing with the hash is that you can clone an app onto a completely different computer, do a build and get the same versioned URIs.

Also, just to be clear I don't think anyone should be asking for automatic version "naming". Only automatic build numbering. You cannot actually auto-increment a version name, because they are and should always be Strings. This is why I had to rewrite SC.browser.compare, because it was assuming that all versions were equivalent series of numbers and thus failing miserably*. Think version names like "0.9beta", "2013-01-24patch2" or "slippery-fish.nightly". The actual version name is dependent on the developer, so simply changing MyApp.VERSION in core.js is sufficient. That's not to say that version naming schemes aren't good to have, only that I don't believe there is any benefit in making them programmatic.

However, the build number is definitely something that the build tools could increment automatically. I've just used Visual Studio for a Win8 SproutCore app and it does exactly that and I'm pretty sure Xcode behaves the same way. Each compile increments the build number, which can be appended to the user supplied version string to ensure that QA and Dev are talking about the same build (ex. MyApp.VERSION + "_build" + SC.BUILD_NUMBER == "iphone,1.1.5_build12").

I can see at least one flaw with automatic build numbering, but it's the same flaw shared by all IDEs in a team environment. The build number file must be committed into the repository or else multiple developers working on the same code will have inconsistent build numbers. Usually only one computer does the actual building, so this may never catch anyone, but it would definitely have to be documented.

Just to keep our context straight, I think we should try to use "Version Name" (ex. "1.3.0rc1"), "Build Number" (37,38,39...) and "Versioned URIs" ("/images/some_hash/bg.png").

Thanks,

Tyler Keating tyler@sproutcore.com

• Not that the improved SC.browser.compareVersion is infallible, but it at least has a better chance of getting it right when version strings look like a series of integers. I'm pretty sure I've written in the docs that I don't recommend using SC.browser for anything more than as a last result.

On 2013-01-14, at 2:18 AM, Maurits Lamers notifications@github.com wrote:

I feel that this versioning needs to be flexible and configurable, so I propose to use something like similar like sc_static or sc_require, perhaps sc_version() that will allow the build tools to insert a version in a specific file of choice. The way this versioning works could then be configurable, say versionScheme: "1.2.x" and the x would then be replaced by an automatically chosen number, which would again be configurable by overriding the standard function.

One of the things that is much easier with the new build-tools is create builds with relative paths. I found that in this case I might also introduce something like sc_deployurlprefix(), as the XHR urls need to be adjustable with regards to the actual deployment. This can make life much easier for many different types of app deployment.

I had a look at both the blog post and the linked deployment guide and to me this way of deploying feels very much like a "one size fits all" strategy. I am currently deploying a CouchApp, and in this case having all the different MD5 hashes would make things more complicated. So I would rather cater a few different configurable approaches, which shouldn't be very hard to do.

@publickeating as you seem to be much more familiar with abbot, what is the mechanism exactly? Is this a MD5 based on the contents of the framework? I have tried to find it, but it is quite easy to get lost in the source.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[mauritslamers]

As essentially I think this is the same issue as #2, I'll close this. Please reopen if you feel different!