GitList and my TODO List

[Dave Hall]

Hi all,

Earlier this evening I posted on my blog some ideas about how I'd like to see GitList progress.  My post is available at http://davehall.com.au/blog/dave/2012/07/13/gitlist-and-my-todo-list. Klaus asked me to move the discussion here.  Rather than copy and post the blog post here, I will start this thread as another response stream to my post.

Cheers

Dave

[Klaus Silveira]

The most important thing right now, imho, is release management. I have no idea of how to do it properly. Maybe implementing semver.org can help?

Dave

--
You received this message because you are subscribed to the Google Groups "GitList" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gitlist/-/-1mkCkNBmQUJ.
To post to this group, send email to git...@googlegroups.com.
To unsubscribe from this group, send email to gitlist+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gitlist?hl=en.

--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com

[Dave Hall]

Hi Klaus,

On 14/07/12 05:37, Klaus Silveira wrote:

The most important thing right now, imho, is release management. I have no idea of how to do it properly. Maybe implementing semver.org can help?

I think using Semantic Versioning makes a lot of sense.

It is probably a good idea to define some milestones to reach a 1.0 stable release.  That way everyone can see what is needed to get there.  This can help others find easy entry points into the project and it also makes it clearer where dependencies exist.   

One way to do outline the roadmap would be to create a wiki page that links to issues and each issue outlines a feature to be implemented or a task to be done and tie this to a milestone.  Another option would be to use something like Pivotal Tracker for tracking this stuff.  I use it for a few clients and it works really well.  Given the volunteer nature of the project it might be too scrum/timebox centric for our needs.

As for the actual release process, github automatically builds tarballs and zips from tags, which makes things pretty easy.  Branch names should match the minor version they are for, such as 1.2.x.  I would suggest that a patch has to land on master before it can be considered for backporting to a branch - that way nothing gets lost and regresses.

Cheers

Dave

[Klaus Silveira]

Hello Dave,

Well, builds are handled by the continuous integration server. So, this is not a problem. I have created a few issues and related those with two new milestones: 0.3 and 0.4. I will create a branch for each major version, and tag minor versions:

• 0.3 - branch
  
• 0.3.0 - tag
• 0.3.1 - tag
• 0.3.2 - tag

I just have to find a decent way to organize this in Jenkins. A TODO seems to be enough, on the README, or do you guys prefer a Roadmap inside the repository wiki?