FireStats 1.2.4-stable
FireStats 1.2 is finally stable (or so I hope).
Download from the usual place.
Navigation
Pages
Categories
Archives
- June 2009
- January 2009
- October 2008
- July 2008
- February 2008
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- January 2007
- December 2006
- November 2006
Meta
FireStats - the blog
3 Responses to “FireStats 1.2.4-stable”
1 Oleg
20 May 2007 @ 1:43 am
Already, FireStats in Russian?
2 Allan Odgaard
30 June 2007 @ 5:10 am
I want to checkout the svn repository directly to wp-content/plugins so that I can easier up/downgrade and inspect changes.
Looking at the repository (at http://svn.firestats.cc/trunk/firestats/) I am not 100% sure that this is really supported ATM though.
E.g. there are no tags corresponding to release versions and some of the files refer to SVN-VERSION, which I assume gets substituted for the actual version when you make a release “build”.
The repository also has a few files, like the Eclipse stuff, which probably should not go into the public repository.
So here’s a request for making the public repository useable for this purpose.
So presumably when you make a stable build, you’d svn mkdir tags/1.2.4-stable (or similar) and svn cp the files included in that build to this tag, then perform the SVN-VERSION substitution.
That way rather than download, unzip, and move the files to wp-content/plugins I’d do:
svn co http://svn.firestats.cc/tags/1.2.4-stable/firestats
And when you release 1.2.5-stable, I can update as simple as:
svn switch http://svn.firestats.cc/tags/1.2.5-stable/firestats
This will even preserve local changes, and also makes it easy for me to ask for a diff between 1.2.4 and 1.2.5 and possibly downgrade if 1.2.5 gives me a problem.
3 omry
30 June 2007 @ 9:29 am
Hi Allan
Currently this usage of the repository is not supported.
the current release flow is:
* each major version change (1.x -> 1.y) gets a branch for bug fixes.
* when a new version is released, an ant build file is executed, which do some manipulation (version numbers and more), and produce the target archive which contains only what’s appropriate for users.
* I didn’t tag the recent versions (although I should have), but this tag would not have been on build output, but rather on the code in the branch the build was ran on.
I will consider creating a release section that will contain what you asked in future versions.
(IE, http://svn.firestats.cc/releases/1.2.5-stable)
about development files in the repo:
the repository is a tool that supposed to help in the development, that’s why I think eclipse files are perfectly reasonable to be there.