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