So, this is one of the areas where you guys can help a lot. So far, new releases of JForum were made available to final users when it "got done".
What is happening with version 2.1.7 is the same thing that happened to previous ones: releases, schedule, bug fixing and etc was centered on a single person (aka, me), which obviously doesn't work so well when you have other things to do.
I would love to have some assitance on these aspects (and not only coding - organization as well).
Answering your questions:
:arrow: When it should be released: I don't have anything else to add, related to bug fixing. There are a lot of features that are interesting, but they don't have to wait for 2.1.7. The only thing we have to do is to freeze 2.1.7 and test it (including the web installer and all databases).
:arrow: What new features it will include: For this, I suggest creating a new page on the Documentation, like a "Release notes for version a.b.c".
:arrow: When it will be turned into a release candidate where only bugs will be fixed: Ok, I'm used to the use of RC's, but in fact I never made a RC for JForum. We can use it for version 2.1.7 already.
What do you think?
Rafael [originally posted on jforum.net by Rafael Steil]
Since we haven't been involved in the process until recently I think it is important that we agree on what 2.1.7 should include. If you say that 2.1.7 have enough new features to soon be changed to a RC, then that is absolutely the best from our point of view.
To have a "healthy" approach to this I will suggest the following:
1) We should create a 2.1.7-branch as soon as we feel we are ready. Only bugfixes are allowed in this branch. Each time a new RC is released we will tag this in this branch. The final version of 2.1.7 will also just be tagged in this branch. This will make it possible to release bugfixes even after 2.1.7 final is release. For example 2.1.7-2 and so on.
The drawback of this approach is that we will have to merge the changes in 2.1.7 into HEAD as often as possible. But I think this is a small price to pay in order to gain control of releases.
As soon as this branch is created we can start doing the tests that you describe.
What do you think?
2) I think that we should have a developers mailinglist where we announce code freeze, release information, branching, and so on. People tend to read mail more often than they read the forum. Maybe the forum suites our needs if the mail-notification starts working again. But I'm a big fan of mailinglists for this type of communication.
3) I think that we should start using the CVS-plugin for Jira. This will make us able to automatically connect code changes to jira issues, just by typing the jira issue id in the cvs commit.
4) I think that all changes to the codebase must be connected to an issue in jira.
5) A release notes page in Documentation is something I applaude. But we have to agree on what information this is based on. Should the developers update it manually or should it be based on reports from Jira? I think Jira is the answer here as long as everything we do to JForum is in there.
For 2.1.7 I think that you, and the other developers involved, should do your best to describe the new features in such a page (If it's not already done)
We can of course help out on this. Just tell us what you want us to do!
[originally posted on jforum.net by lazee]
Eat that pie! EAT IT! Now read this tiny ad. READ IT!