Open jtickle opened 11 years ago
jtickle
commented
11 years ago NB, this does not mean that every single commit gets a tagged version, that'd be insane. But once you're in 1.8.3 and have done a few commits and have the bug fixed, you can tag 1.8.4. The number of commits between 1.8.3 and 1.8.4 will probably be in the 2-3 range, but the number of commits between 1.8.x and 1.9.0 could well be in the hundreds.
Stardog
commented
11 years ago I agree.
jlbooker
commented
11 years ago Sounds good to me. We should definitely make it easier to prepare a release, so that any of us can do it as needed.
We should also start planning ways to make it easier on our sys admins to keep up with these releases. A public yum repo (with production and beta packages) wouldn't be a bad idea.
jtickle
commented
11 years ago /me dons my package maintainer hat
The RPMs we use internally and the .spec file in the repo are very much designed specifically for our internal setup. I definitely like the idea of a public YUM repo but first, I need to be able to use software configuration to do this:
And then I need to sanitize my hub/branch management shell scripts for /usr/bin, and extend them to create apache configuration.
It's a goal to work towards for sure but we need the above first.
For now, I can configure Jenkins to create tarballs however we need it to, and I'll get with Matt to figure that out.
jlbooker
commented
11 years ago Sounds good. Do we have issues for those things? Let's make sure we figure out exactly what changes are required for the bullets you listed above, and then make issues (if needed, or notes on the existing issues) for those changes and get them planned on a milestone/release (according to the new release strategy, of course). Depending on how much we have to break in order to make the needed changes, that'll determine how soon we can have a public rpm package.
jlbooker
commented
11 years ago I've updated the milestone labels according to this proposal.
Initially, we had a nice plan: Let's make major changes to phpWebSite, call it 1.8.x and maybe 1.9.x, and don't break compatibility until 2.0.0.
We have now "released" 1.8.1 at least ten times. This is a pretty bad practice to get into, and really that minor version number should never be used for new features, but only for bug fixes. Additionally, we need to release early and often, and frankly there is no way in the real world that we're ever going to just put out a 1.8.2 and not have to fix something in it before 1.8.3 is ready.
Therefore, I propose that we release VERY often, potentially several times a week. The downside is that if even one line changes after a package has been built and put on the website, that one line will require a minor version number. But this is how everyone else does it, and it ensures that a version number refers to a specific revision, and not the latest in a family of revisions.
May I suggest the following convention:
1.8.2 - 1 is Major, 2 is Mezzo, 3 is Minor.
With our current milestone structure, this would make 1.8.2 become 1.9.x; 1.8.3 would be 1.10.x, etc. And the fix to newlines in logging would become 1.8.2, and some other fix to some other yet undiscovered bug would be 1.8.3.
Our repository would then be laid out like this:
Branch 1.8 Tag 1.8.0 Tag 1.8.1 Tag 1.8.2, etc Branch 1.9 Tag 1.9.0 Tag 1.9.1, etc Branch 1.10, etc
Now what you have to keep in mind is that if someone submits a bug, you need to find out where that bug originiated. If we're working on 1.10.x and someone submits a bug that originally happened in 1.8.3 but affects code in 1.10.x:
I know releases are a pain but we can script that stuff and make Jenkins do it for us. It can even deploy the files to a web directory, all we have to do is update the website.
Thoughts?
┆Issue is synchronized with this Asana task