When do you tag your software project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question 开发者_JS百科

I realize there are various kinds of software projects:

• commercial (for John Doe)
• industrial (for Mr. Montgomery Burns)
• successful open-source (with audience larger than, say, 10 people)
• personal projects (with audience size in the vicinity of 1).

each of which releases a new version of their product on different conditions. I'm particularly interested in the case of personal projects and open-source projects. When, or under what conditions, do you make a new release of any kind? Do you subscribe to a fixed recurring deadline such as every two weeks? Do you commit to a release of at least 10 minor fixes, or one major fix? Do you combine the two conditions such as at least one condition must hold, or both must hold?

I reckon this is a subjective question. I ask this question in light of searching for tricks to keep my projects alive and kicking. Sometimes my projects are active — but look as if they aren't because I don't have the confidence to make a release or a tag of any sort for a long time.

---

For all my personal projects and prototype projects I do at work I release builds when the completion criteria for my current milestone is complete.

In essence...

1. I make a plan, including the things you definitely want and some things that would be nice to have in the next official build
2. I work on those things until they meet the desired level of functionality as defined in the plan
3. Then I label a release

On my personal projects I rarely have a timeline (since it's a hobby), so step 2 often has no strict deadlines, in the case where you have deadlines and they arrive but the plan isn't complete then you may have to cut some things from the plan and make a release anyway. In many cases it's better to release something that has only 50% of the planned features but they all work and are well tested than wait until 100% of all the features are fully complete.

---

We have a release schedule, major release every M months, minor release every N months, where M > N. We know we will need to make a major release every M months as we work with the government and they add required functionality every 6-12 months, and the minor releases are bugfixes or new features as suggested by customers.

Minor releases might get pushed back or coalesced into another release, depending on what fixes/features are going in and how busy we are with the major release.

Approximate turnaround time for a bug found to being fixed in a minor release is 6 to 8 weeks.

---

It really depends on the project and the urgency of the release. In most cases, I prefer to have a regular build schedule (usually weekly) and stick to it unless an emergency patch is required for a show-stopper bug. However, for production releases, there should be a phased build cycle -- perhaps monthly. As you stated though, it's very subjective.