On July 12, 2013 Lieven wrote:Nice, thanks. I also found a JSON version of the same list that should be easy to
> Op 13-jul.-2013, om 16:06 heeft "Michael Stovenour" <email@example.com> het volgende
> > Do we plan to support downloading of previous versions of MisterHouse?
> We already do: https://github.com/hollie/misterhouse/releases
Both the api and the releases page work off of git tags; here the assumption is that tags
are "only" used to tag releases.
I like automation :) Especially for the release process. Changing download.pod to point
> > 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).
to this URL will work so long as someone rewrites code/common/mh_release.pl. See below
for my comments on this idea.
Nice, thanks again.
> > 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.
Using the tags API URL should make this rather easy. I'll volunteer to modify the
> > 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?
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!
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365