If you take notice of the below attached screenshots, you will see how there are older listed in the JIRA as when compared to those that are listed on the uDig download page. Perhaps you can better explain to me(and others) how the transformation/evolution process occurs? Meaning, when a uDig release makes it to the uDig downoad page(e.g.- uDig 1.1.1), should the JIRA references to 1.1.1 be then changed/converted to uDig 1.1.2 for example? Meaning, when a release is made, like uDig 1.1.1, users now have that release, and any such user that indeed files a JIRA bug report, will indeed be filing it against that 1.1.1 version. So, the JIRA should in fact have the option for the user to report against 1.1.1 in the selection process, and in the versions section of the JIRA, the active reference should be 1.1.2(or whatever ascending version number is used after 1.1.1), correct?
When I look at the JIRA, and see uDig 1.1-RC13, 1.1RC14, 1.1SC1, and 1.2.M3, 1.1.2M4, it provides a bit of confusion for me, because there are both older versions and newer version being listed when compared to my 1.1.1 release version being used. I understand that there are specific efforts/builds that are satisfying individual interests/projects, but in general, and for the sake of simplicity for the end-user(meaning assuming a person has no previous experience with uDig, it's development, or it's developers-active or not), would it not be beneficial to reduce this to merely and only the subsequent version(1.1.2 for example), with reporting options for 1.1.1 and 1.1.1 only? If a user is using an earlier version of uDig(1.1.0 for example), s/he should not be given the opportunity to report a bug on that version... it causes to much overhead. Users should be made aware on the JIRA that any and all tickets should only be filed against the latest release build(1.1.1 for example), and in the JIRA those tickets are applied/attached to the 1.1.2 version. Any specific or individual efforts that employ a particular version, should also have their own specific area for ticket filing(uDig 1.1-RC13 for example). Also, uDig should also make as a rule that only the latest(or last) version of the respective operating system is the one that is considered when checking/testing against filed tickets(bugs).
If possible, the JIRA should be setup/configured so that the first menu selection the user choses is the OPERATING SYSTEM(Windows XP, Windows Vista, PPC OS X, x86 OS X, Linux, etc.). In fact, the user should be prompted to push a button, which in turn queries the system information of the user's computer, auto-populating the JIRA with OS version, Java version, applicable hardware(amount of memory, # of processors/speed, etc.). In general, the only version that should be having tickets filed against it should be the latest release version(1.1.1 for example), and the only version it should be applied towards should be the current development version(1.1.2 for example). For all other release versions and development versions, those should be isolated and made distinctly different/separate, because in fact they ARE distinct and specific, and serve a specific individual or group of individuals(or a company/project), instead of the entire uDig community/project/software application as a whole. Again, I've said this many times before... the JIRA should be constructed with the assumption that the person filing the ticket has absolutely no prior knowledge of the uDig project or it's history/inner-workings. It should be dead-simple, and should pose the structured questions so the user need not have to know anything about the project, but instead merely and easily select a few pre-defined answers to the few posed questions, and then type in their ticket(bug or feature request) details explaining the bug/feature request, and press submit. Upon pressing submit, the dedicated users who test against specific operating systems receive an email with the ticket, so they can read it, understand it, and then test it against their respective operating system version, which should be the latest, as should be their Java installation, as should be their uDig application release. If these dedicated uDig system-specific ticket checkers are unable to understand the ticket, the dedicated users should be able to easily send a message to the person who filed a ticket as to get further clarification, and in the event the dedicated uDig ticket checker does not get a timely response from the person who filed the ticket, the dedicated uDig ticket checker should have the one-click option of being able to delete that ticket all together.
Right now any John or Jane Doe that goes to the uDig download site is given the opportunity to download release 1.1.1, 1.1.0, and 1.0.6. However, it should only be users of 1.1.1 that need file JIRA tickets. uDig is not a large enough project, and does not have enough resources, to be managing all these release versions. Until it matures to such a point, it should, by design, only ever at any one time, provide users with the ability to file against the latest release version(1.1.1), and in general should only have one development version(1.1.2) to which those tickets are applied. For all other release and development versions, those individuals(projects/businesses) who are actively using/working on those specific versions, should in fact have their own project/version-specific section in the JIRA, that is clearly not commingled with the staple/base/general uDig release & development application. Perhaps the JIRA has menu selection that instructs the user if they are using a version other then the current release version, that they are in effect using a version that is part of 'project x' or 'project y' or 'project z' for example. And these project x's are specific to a particular effort or collaboration for a particular user base/project/company/etc., hence their existence, hence their clear separation and distinction.
Also, it is very important that the builds for each operating system always remain uniform and standard. Release versions(1.1.1 for example) should always install normally, placing the respective uDigWorkspace folder into the user's Documents folder(as is the case on OS X for example), whilst development releases(1.1.2/trunk for example) should contain said folder(s) in the package itself, or in it's own uDig folder, so that the testers/checkers can easily be running the release version and the development version at the same time, without either of them interrupting with the other's files/configurations. This will allow testers/checkers the ability to easily download the latest development build from the main programmers efforts, install it, and then test/check it against all the respective tickets they have on their plate from previous JIRA ticket filings, which they have served as tester/checker.
This process is repeated until the bug is fixed across all platforms. In this scenario, we make sure that the latest Release version of uDig is the primary focus, and we make sure that when a uDig programmer fixes(or attempts to fix) a Bug, s/he makes builds for OS X, Windows, and Linux, so that the dedicated testers/checkers may download latest Development version, check any Bug tickets, and report back accordingly.
Thoughts/Opinions/Ideas?
