Publish a 'rc/version.txt' file when doing a 'phing release-rc'

@raamdev writes...

I wonder if there's a way to tweak the Phing build system to account for this scenario, where there might be a stable version, a Release Candidate, and then a bleeding edge... I mean, I suppose we could just do an RC release like a regular release, and then require the software itself to determine if the version is RC or not (e.g., stable and RC releases would be done via the build system in the same way, but the Comet Cache update system would parse the version number to determine if the latest version is an RC version... but then we'd still need a way to retrieve the latest stable version, as opposed to just the very latest version (which may very well be an RC, and not actually the latest stable version)).

@jaswrks writes...

Interesting idea. I was just looking over the directory structure that we use now. https://github.com/websharks/team/wiki/AWS-Uploads-via-Phing

That's pretty much the case already, the only thing that's missing is an rc/version.txt file showing what the latest RC release version is. At present, there are two version.txt files. One showing what the latest stable release is, and the other showing what the latest bleeding edge version is.

So we could try doing what you suggested and add an additional version.txt that would automatically be created when running phing release-rc.

@raamdev writes...

Yeah, that sounds like the easiest way to resolve this. With that in place, we could have a stable version, and RC, and a bleeding edge existing all at the same time, and we won't have to worry about building a bleeding edge when we're in the middle of an Release Candidate creating any conflicts.

wpsharks / phings

Publish a 'rc/version.txt' file when doing a 'phing release-rc' #159