Hi Lieven,

That SourceForge page ( http://misterhouse.sourceforge.net/ ) actually points to the v3.00 zip even though it says v2.200.

My issue is with the http://sourceforge.net/projects/misterhouse/?source=directory page that still lists the last version that was built on SourceForge v2.103 (sorry misread it before) that dates back to 2008... Looks bad...

It could really do with a newer zip uploading there... Or the whole project page just taking down...

I would also add that there was a reason for the 'Stable' release of MH, things go wrong sometimes weeks after release and non-devs don't need the aggro that goes with bleeding edge code, hence the stable and latest releases in the old system.

Lee 



On Thu, Jul 18, 2013 at 9:16 PM, Lieven Hollevoet <lieven@lika.be> wrote:
Hi list,

Lee has a point. It is OK to keep various locations to point to the latest MisterHouse for historical reasons, but we should at least ensure that all locations link to the latest version. The SourceForge page still lists 2.200 as being the latest stable release while 3.0 is already out for some time...

Would it be a problem to just put the link to the github zip there? Then all download links that I know of point to the latest stable automatically. (The wikispaces page already links to the latest zip).

Kind regards,
 Lieven.

Op 18-jul.-2013, om 15:49 heeft Vargster <vargster@gmail.com> het volgende geschreven:

> I think the bigger issue is that the old v2.105 code is still up on SourceForge. AND people are still regularly downloading it. Over 2,000 downloads THIS year so far...
>
> Lee
>
>
> On Sun, Jul 14, 2013 at 1:55 PM, Michael Stovenour <michael@stovenour.net> wrote:
> On July 12, 2013 Lieven wrote:
> >
> > Op 13-jul.-2013, om 16:06 heeft "Michael Stovenour" <michael@stovenour.net> het volgende
> > geschreven:
> >
> > > Do we plan to support downloading of previous versions of MisterHouse?
> >
> > We already do: https://github.com/hollie/misterhouse/releases
>
> Nice, thanks.  I also found a JSON version of the same list that should be easy to
> automate.
> https://api.github.com/repos/hollie/misterhouse/tags
> https://api.github.com/repos/hollie/misterhouse/zipball/v3.0
>
> Both the api and the releases page work off of git tags; here the assumption is that tags
> are "only" used to tag releases.
>
> > >
> > > The "download" page in the official documentation was not updated for v3.0.  That page
> > lists the current version and one version back (i.e. v2.0 and v1.105 ).
> >
> > Is there a specific reason for maintaining a separate webpage that states the 'latest'
> > version when there exists an index page on github that is automatically updated when we
> > release a new version in the repo (see link above). The consequence of having a separate
> > page that needs to be updated manually is that is gets outdated. Why don't we link to
> > the releases page on the github page. It should be rahter obvious what the latest
> > version is (the topmost one).
>
> I like automation :)  Especially for the release process.  Changing download.pod to point
> to this URL will work so long as someone rewrites code/common/mh_release.pl.  See below
> for my comments on this idea.
>
> > > The current version points to "stable.zip" on GitHub.  If I wanted to roll the
> > versions forward one, how can I get a copy of the old V2.0 of the "stable.zip" file?
> >
> > See the releases page above.
>
> Nice, thanks again.
>
> > >
> > > When the mh_version.pl common code file is enabled, MisterHouse checks this download
> > page for new versions and notify the user that there is a new version.  Real handy when
> > we push out updates to stable, but it relies on someone remembering to change
> > docs/download.pod and regenerate the official documentation.
> >
> > Would it be a problem to link it to the new page in the mh_version code? The only thing
> > I can think of is that we need to remember to state on the old page that the new version
> > (that contains the updated version check code) is available. From then on users should
> > get the latest version page directly from the github page?
>
> Using the tags API URL should make this rather easy.  I'll volunteer to modify the
> mh_version.pl file but I would like to understand the rules around tag usage and naming.
> It would be good if we had some documented rules for identifying the latest release.  I
> suspect we will need more criteria than simply picking the top most tag; top most is most
> recent but will that always be the latest and will top most even always be a release?  How
> do you see us using tags over the life of the project?  What rules do you think are
> appropriate for a piece of code to unambiguously find the latest release?
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>