Skip to main content
Topic: The release game (Read 3801 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The release game

I'm a release noob for sure, so, what is generally needed for a release?

I can think of:
1) a working script,
1a) some testing,
2) a place where it can be downloaded,
3) ????
4) PROFIT!!!!
...oh, no wait it doesn't work that way! :P

What else?
Bugs creator.
Features destroyer.
Template killer.

Re: The release game

Reply #1
install / upgrade instructions.
Thorsten "TE" Eurich
------------------------

Re: The release game

Reply #2
Bump for part two: quality.

Let's face it: at the moment the project is not in a position to effectively test everything. Automated testing covers a very limited part of the code (it's mostly a demo), and there aren't many people testing it (of course a limited but active number of tester is still much more effective than a large but inactive set).

So, let's assume today we decide to release a beta, how long should it be tested live here (that I think is by far the most effective way to test it at the moment) before the product can be considered "stable enough" for release?
Obviously non-final and final are two different beasts: betas are mostly untested (at least not deeply tested) and may require more time to reach a bare minimum stability, but can be released even with some glitch. Release candidates (in the original sense of the term, so a release that may just receive a change in the name to become final) on the other hand should be as much as possible "bug-free" (okay, let's say...without known issues), but they should be already much more tested (considering the beta/s before) and so should have very few minor buglets, but these buglets may be more difficult to find.

I think that during the latest site upgrades, most of the bugs have been discovered in no more than a week: the most critical are discovered immediately while upgrading, the most important are identified in the first day or so, and the rest (maybe even important, but in some "remote" page) are discovered usually pretty soon after.

Considering our next and first release is a beta, I think we could accept some risk and say that one week of testing here should be enough to guarantee that any major feature works as expected and major bugs are identified.

Does it make sense?
Bugs creator.
Features destroyer.
Template killer.

Re: The release game

Reply #3

Considering our next and first release is a beta, I think we could accept some risk and say that one week of testing here should be enough to guarantee that any major feature works as expected and major bugs are identified.

Does it make sense?
Yep, makes sense to me. We don't need an inifinte test cycle for beta and we can still fix small/hidden bugs within the nornmal release cycle. 
Thorsten "TE" Eurich
------------------------

Re: The release game

Reply #4
Bump for part two: quality.

Let's face it: at the moment the project is not in a position to effectively test everything. Automated testing covers a very limited part of the code (it's mostly a demo), and there aren't many people testing it (of course a limited but active number of tester is still much more effective than a large but inactive set).
Yup, its just the basic framework, we need to figure out some real test cases to see if what we have will help take some of the testing workload ... maybe during beta or rc stages we can look at that a bit more
Quote
I think that during the latest site upgrades, most of the bugs have been discovered in no more than a week: the most critical are discovered immediately while upgrading, the most important are identified in the first day or so, and the rest (maybe even important, but in some "remote" page) are discovered usually pretty soon after.

Considering our next and first release is a beta, I think we could accept some risk and say that one week of testing here should be enough to guarantee that any major feature works as expected and major bugs are identified.
Makes sense to me, beta is our way of controlling our us, e.g. stop adding and breaking :D, plus we have had the benefit of running the software here for some time, which is a benefit as well.  Some areas of the code have not been messed with in some time should be stable at this point.  Each time we refresh the site, the bugs always tend to be 90% new and 10% old things we stumble across in remote pages etc.

Re: The release game

Reply #5
Where are we going to store the package?

TE mentioned github's releases: https://github.com/blog/1547-release-your-software
It looks rather interesting I think.
I tested it on one of my mods (and old one for SMF O:-)):
https://github.com/emanuele45/Force-New-Password/releases
It looks rather nice to me.
The page is not terribly flexible (for example we'd have to provide both upgrade and install packages on the same screen, that doesn't sound nice), but we could just create a page or a topic here and provide the link to the download package.
Alternatively I think we can always fallback on SourceForge (I just created an empty project for the fun of it O:-)) if releases doesn't work for any reason, or we can use both or another one if there are alternatives.

Also, I think it's almost time to think about translations too.
We don't have a dedicated tool at the moment.
Weeks ago I tried to make Pootle work on my computer, but I failed. Well, I was "close", but it didn't work very well.
I've never used it, though it looks nice, for example:
https://translate.apache.org/
It works with many formats including php based like the one we are using. It should allow on-line edits as well as download/upload of translated files.

That's an option, not the only one.
For example, for the time being, we could just work with attachments (here) and push changes to a repository and then release the file.

Other ideas?
Bugs creator.
Features destroyer.
Template killer.

Re: The release game

Reply #6
I have this little mod of mine:

http://simpleportal.net/index.php?topic=10929.0

Well, maybe not so little, with a few thousand lines of code. I have always wanted to work more on it, but could only spend a couple of days on it. Here is a little post on how it works from translators' perspective:

Quote from: me
In the Languages List, you'll see all languages with progress bars and [edit] [export] links (only for the ones you can modify). To start working on your language, you follow the [edit] link.

Once you follow [edit] link, you'll end up on the File List for the language you selected. You'll have [edit untranslated] and [edit all] links in this list. [edit untranslated] link will list you only the untranslated strings to translate. Whereas [edit all] will all strings.

Following one of those links, you'll get to the Edit File page. You'll get 10 strings per page. You can use Next Entries and Previous Entires buttons to navigate. Only thing you need to do is, fill in the Translation box with the translation of the string. If the string will be same as the English version (like "SimplePortal" titles) then you need to check No Translation option for that string, so that it won't appear as unstranslated. Once you are done, you can save your changes by clicking Save Changes button. If want to leave without saving click the Discard Changes button.

Note that nothing will be saved unless you click the Save Changes button. While navigating through the entries, your changes will be kept in a temporary file and the original strings will only be updated when you click the Save Changes button. Also, if you'll have to leave the page without saving for some reason, you won't loose your changes. However, you still need to use the Save Changes button to apply those changes.

Lastly, you can use the [export] link in the Languages List to export the language. Once the package is created, you'll be a given a link to the package. You can also view and download created packages through the Packages area, Packages List section.

It's pretty simple and straightforward and has plenty of cool features like importing language files or synchronizing languages for updated entries or accounting for the case in which more than one user edits the same file at the same time. But it probably also has plenty of nice and lovely bugs since I could only work very little on it. Still we've been using it at sp.net for some time without any problems. So if you're interested, I could share the code.

Re: The release game

Reply #7
Looks... O_O

 emanuele would be glad to see it in action if possible... O:-) (I have at account at sp.net)

BTW:
http://xkcd.com/844/
Bugs creator.
Features destroyer.
Template killer.

Re: The release game

Reply #8
Quote
I have this little mod of mine:
Looks awesome, would love to have you share the code so we can check it out.


I tested it on one of my mods (and old one for SMF O:-)):
https://github.com/emanuele45/Force-New-Password/releases
It looks rather nice to me.
Thats not bad really  :D  , plus it uses the tagged file name unlike the master branch.   Should we add a github page as well?

Quote
Alternatively I think we can always fallback on SourceForge (I just created an empty project for the fun of it O:-)) if releases doesn't work for any reason, or we can use both or another one if there are alternatives.
Thats not a bad fallback position if for some reason the github one does not work out. 


Re: The release game

Reply #10
I've sent the URL to the package to both of you. I've also given translator access to both of you at sp.net.

Re: The release game

Reply #11
[SiNaN], that translation tool looks really nice. Well done..
Thorsten "TE" Eurich
------------------------

Re: The release game

Reply #12
Thank you! I could send you the package as well, if you wanted to take a look at it.