Hi Michael,

On Fri, Jul 19, 2013 at 8:10 AM, Michael Stovenour <michael@stovenour.net> wrote:

On July 18, 2013 3:39 PM Lieven wrote:
> first of all I have documented the process on how to create a new stable release here:
> https://github.com/hollie/misterhouse/wiki/Release-process-of-a-new-stable-release

Thanks Lieven.  My OCD
(http://en.wikipedia.org/wiki/Obsessive%E2%80%93compulsive_disorder) is settling down now

Well, glad I was able to help here :)
Just two comments:
Did you mean to leave this paragraph?  It seems like you are missing the content of the
        Then, update the version number in the VERSION file (should contain .).
The "should contain" part seems to be missing.

Hmmm, it contained <major>.<minor> but the characters between the brackets got eaten up by the wiki formatting. Fixed it. 

Do you mind if I add some steps to:
        Document how to update the official user documentation
        Copy the stable zip file to various yet to be determined locations (maybe just
        Notify various forums, mail lists, etc. of the new release
I never have a problem with people adding documentation :)
Please go ahead, I already added a link to existing documentation on how to contribute in the text you added.  

> Secondly, I propose the following 'simple' numbering scheme: we're now at 3.0. If we
> deem it useful to make a new stable release that contains minor changes/fixes/additions
> we up the minor version number, however we don't pass 9 on minor version numbers as this
> is confusing for users (is 3.101 newer than 3.2?).
> Of course if we think it is interesting to have a major version increment, e.g. when we
> add this fully AJAX-based dynamic web 3.0 web interface (theoretical example of course
> :-), we up the version to 4.0. This can happen before we end up with 3.9 depending on
> what we as developers decide to be the best solution.
> Now on the automatic version check you asked about. If we can agree that we call the tag
> of the stable releases in the repo to be in the format of
> v<major>.<minor>
> then we should be able to parse the latest release to be the top-most release on the
> JSON page you linked to.
> I don't think we will ever put tags on non-stable releases (those developments go into
> branches but not in a tag) so we should be able to safely say that the topmost tag in
> the JSON output is the most recent release.

I like it.  I can modify the version check to look for the "first" (i.e. top most) tag
that matches the pattern /v\d+\.\d+/.  That should cover us if someone creates a tag for a
different use.

Yes, that regexp was what I had in mind too!

Do you mind if I add the text above to a wiki page?

Not at all. Please go ahead.

Kind regards,