In a few words, why are there so many version changes to this SW?
Because features are added so rapidly.
and bugs fixed even quicker - well, inmost cases
Joe91: that’s a whole lot bugs revealed by the user testing.
Most commercial software has a team of programmers with a release schedule many months in duration. Internal versions are tested internally and released internally rapidly. In contrast release version changes are set early, implemented, tested internally, beta tested then released. An inherently time consuming and expensive process.
In contrast Manager changes are implemented, internally tested the released.
As a result Manager is very responsive to user input, features are improved very rapidly and can be supplied very economically. It also means the public sees a rapid succession of versions
I won’t be surprised to see many other companies adopting Manager’s software building style.
Just a question… does anyone know if Manager is a one man software or there’s a group of programmers behind it?
generalegend: “Manager.io” as a permanent “Beta version” Yep, I think you nailed it. Permanent Beta Version
Patch: IMO the major benefit of Manager is that it is FREE, if users can get by with it.
Patch: I agree with the “rapid succession of versions”.
Davide: one man SW, when adding up the collective wisdom on the SW
That’s very impressive but also very frightening. What will become of us if @lubos suddenly decide to change life and devote himself to fishing? LOL
@lubos LOL fishing. try the Yates No. 3 L-Y Spoon Fishing Lure.
How is the manager version updated and where do I get the new version?
Procedures vary by operating system. Update exactly as you first installed. There are Guides for Windows and Macs. Download from the Download page.
A few things beyond the standard Find->Fix->Test-Release cycle:
• A bug should have multiple assignments, so it can be assigned to one person for fixing, and another person for testing it, instead of being assigned to a single person.
• Your bug track system must track all history of what was changed.
• Keep track of what version a bug was found in, was fixed in, was tested in, and then was released in. They are all different and important values.
• Have the ability to change an issue from a bug to an enhancement.
• Have a status for “question” or “waiting for answers”, to represent questions have been sent to a business analyst, essentially blocking progress on the bug.
• Keep a bug restricted to a single issue, so that you can verify whether that issue is actually fixed. So if there are 3 things wrong with a screen, log 3 bugs, instead a single of “Issues on the Whatever Screen”; these bugs may be fixed and released individually, and you need to be able to track that.
If I was a new owner or senior manager of a software business I would consider cautiously constructing such a list.
However as a user of a software program, my expectation are not even on the same page.
As a user I get to choose which software programs I use, and generally that is all. With Manager there is a forum to “suggest improvements”, and if I’m lucky they will be read by a developer. Developing software to achieve and maintain adequate market share is a much more difficult task then coming up with ideas which make sense from my perspective as a single user.
As for the details of your request, you are suggesting Manager carry the same overheads as the large software organisations you are familiar with. I think that is probably a bad idea.
Profitable businesses persist.
Unprofitable businesses disappear.
Owners can come and go