I think we should focus on stability, reliability and lessening the pain for administrators of GitLab. IMHO the following points should all be addressed before releasing 4.0 (delaying the release if necessary). Any PR/enhancement that is not aimed towards one of those goals should be postponed for the next release. Any issue/PR that needs to be closed before release should be assigned to the 4.0 milestone.
Information/Diagnosis
:no_entry::sweat: Create a proper about page (#1993 (closed))
a rake task that gathers basic information (GitLab version, Gitolite version, distro, etc.) for copy and paste to issues (#2194)
make gitlab:app:status task more useful, checking a lot more that now (e.g. are users in the right group, dir/file users/groups set correctly, dir/file permissions set correctly, Resque working, mailer working, cloning over http(s) working, ...) (#2004 (closed))
for all checks offer instructions to fix them (#2266)
I'll be reviewing submitted issues to see if there still relevant/up to date (like #1917 (closed) is not relevant anymore because sqlite support is removed, right?)
By Administrator on 2012-12-03T22:06:36 (imported from GitLab project)
By Administrator on 2012-12-03T22:06:36 (imported from GitLab)
I'm talking about all the to milestone-v4.0 assigned issues. They are now just passed along to the next version but is this good? I think there should be a better, more clear way of how the versioning goes. So define targets upfront, with maybe some occasional issue squeezed in, and don't release before they are done, and if this means that there is can't be a release on every 22th of the month, so be it. What is the value of a forced monthly release anyway? Maybe following the guidelines of Semantic Versioning could also make things clearer.
Anyway, currently the version numbers could just be dates, because they don't say nothing about the state of the software.
By Administrator on 2012-12-21T01:11:20 (imported from GitLab project)
By Administrator on 2012-12-21T01:11:20 (imported from GitLab)
@koenpunt All critical issues are fixed. I dont think we should delay release to fix all of them. Also dont forget that a lot of issues can be done or not depend on contribution. So its hard to squeeze them. And we complete major goals for this release i think. I like the way ubuntu releases with fixed schedule.
By Administrator on 2012-12-21T07:06:17 (imported from GitLab project)
By Administrator on 2012-12-21T07:06:17 (imported from GitLab)