Problem description: https://wiki.documentfoundation.org/QA/Meetings/2013/November_04#PENDING_ITEM:_Updates_to_the_BSA Steps to reproduce: 1. Open BSA 2. Pick the 'WWW' Component 3. Pick the 'BUGZILLAASSISTANT' subcomponent 4. Version the bug appeared: 3.3. all versions 5. OS: All 6. Latest-know-working version: NONE Current behavior: I can file a bug against an EOL version of LibreOffice using the BSA. Expected behavior: Using the BSA, I should only be able to file bugs against current versions of LibreOffice [This bug is the demonstration that it's still possible to file this type of bug using the BSA] Operating System: All Version: 3.3 all versions
Adding Rob
Still possible
I'm all in for this. I understand the policy of LO not only offering the latest stable build (currently 4.1.3.2) but also 4.0.6 for more stability. But we should encourage users very strongly to only file bugs against those two stable builds. We could use later for everything else and have the user specify the version in the report if they e.g. work in a company and have no control over which LO version is being used. Currently incentives to use the latest stable release are much to low. This would be an important step (amongst others), so +1 from my side!
We can get a list of current stable versions of LibreOffice from here: http://download.documentfoundation.org/libreoffice/stable/ [Note: That list might be a little behind the EOL dates per the ReleasePlan page, but it won't lag more than about a month] Rob wonders: Can we get that list in something easier to parse, such as JSON or XML? Cloph - Thoughts on how difficult it would be to output in a different format? --- In the meantime, we can have an hourly cron job parse the page with something like this: qubit@lo~$ sed -n 's/.*<td><a href="\([^/]*\)\/.*[0-9][0-9]-.*/\1/p' stable.htm 4.0.6 4.1.3 Actually, JSON would be even easier to deal with: sed -n 's/.*<td><a href="\([^/]*\)\/.*[0-9][0-9]-.*/"\1"/p' stable.htm | paste -s -d, | sed 's/\(.*\)/[\1]/' > /somewhere/for/bsa/stable-versions.json Cheers!
Mirrorbrain has no API for this, unfortunatly. I don't know how the libreoffice update-checker is formatted. It is at http://update.libreoffice.org/check.php but I can't access it as i'm not libreoffice (don't know how it checks)
(In reply to comment #5) > I don't know how the libreoffice update-checker is formatted. > It is at http://update.libreoffice.org/check.php but I can't access it as > i'm not libreoffice (don't know how it checks) The updater currently has all of the data embedded into the php file. I'd like to automate the addition of build-hashes upon each new release ANYHOW, so we should split that data out into a separate file or store it in a db first.
Updated algorithm has been included as of https://github.com/tdf/www-bugassistant/commit/682708133b4bc7f2ad96cb76bc41e8ad602940d9 Site updated today. Looks solved to me. Joren - try to break this, please?
(In reply to comment #7) > Updated algorithm has been included as of > https://github.com/tdf/www-bugassistant/commit/ > 682708133b4bc7f2ad96cb76bc41e8ad602940d9 > > Site updated today. Looks solved to me. > > Joren - try to break this, please? Sadly I can't. Tested with Firefox 26 and Safari 7.0. Looks fixed to me :)?
done de done done
Woot! Wanted this for so long :)