Posted by CorniI on June 7, 2009 at 2:50pm
Jump to:
| Project: | Version Control API -- Git backend |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | git phase 2, release |
Issue Summary
Hi,
we need to discuss if we
a) Want to release a stable vcs_git for the VCS API 6.x-1.x branch and later port to the OOP API and support both releases, or
b) want to wait for the OOP API, follow it quite soon and release just a 6.x-2.x branch with the OOP code and release a final release together with the VCS API (maybe combined with the other modules chrono325 is developing)
Another point is that I propose to continue to release alphas when one of the filed tasks are done, when most are done we start with betas and when all are done, we start with release candidates. That's also the point when start to provide update paths to the next version.
opinions?
Comments
#1
The code that dhax and marvil07 are developing will take a while until it's done, and might take some more time to get it properly merged into Version Control API. And who knows which kinds of changes a 6.x-2.x version will receive in addition to those.
Overall, I'm a big fan of stable releases when I know that the DB storage won't change (or is at least unlikely to change). Writing update functions is awful, but then again you'll probably have to do it anyways if the schema changes.
Also, I think that people will use releases compatible to 6.x-1.x, because nothing remotely stable will come after that for quite some time. Not releasing a stable version for 6.x-1.x will most probably limit the number of module users. Whether you want that or not depends on how much support you want to provide to your users (in terms of upgradeability, support request replies, and bugfixes).
Also, consider that if you release two major versions then only one needs to be "recommended"/"supported", and others can be selected to appear as "unsupported". Personally, I pretty much freeze my stable branches except for critical bugfixes, and no one has complained about that yet. (Maybe that's also a side effect of low user counts for my modules.)
#2
From what I can see, A and B are pretty much the same thing: 2.x would be the OOP port. The core question is whether 1.x will be supported once 2.x comes out. I'm a big fan of stable releases (i guess everyone is) the question is how to do it. I'm also a big fan of *frequent* releases, which often ensure more stable releases, especially if you don't have the manpower to handle multiple branches (which are a pain in CVS, ironically enough).
So my vote would be to release 1.x without OOP and then port quickly to 2.x. If the 2.x release is quick and compatible enough, you will not *need* to maintain the 1.x anymore.
#3
HEAD on versioncontrol module now is OOP, so I've just finished to move my oop-branch of this backend to cvs HEAD too.
Now, we are in the process of decide how we're going to make the releases: #595930: from github to d.o cvs(aka start 6.x-2.0-dev and get access), so I think we could postpone this discussion until versioncontrol module have a clear desition about it
#4
Well, finally I could close that enormous issue :-)
I also tried to made a summary about the release versions on versioncontrol project page, and looking at api usage it seems like
6.x-1.xhave the majority of the users.So, making the analogy for the git backend, and looking also at its usage
6.x-1.xbranch seems to be the more used one.In the other hand, like I mentioned on versioncontrol project page:
I have no plans to continue
6.x-1.x, so I definitely suggest to use 2.x as the recommended release when git backend have at least a beta, which should depend on a versioncontrolapi6.x-2.xbeta(or stable if possible :-)).I think the best idea(since there are no so much users by now) is to have only one stable release. I vote for making a
6.x-2.x,stable ASAP and leave6.x-1.xas it's now(do not maintaint it in favour of 2.x release).Like mentioned before, git backend
6.x-2.xis already synced with versioncontrolapi6.x-2.x, so I suppose I should put now the main effort on versioncontrolapi until I have a beta :-)any suggestions?
#5
Ok, I think we are way too late here for making a stable 6.x-1.x release for the git backend, since the current activity around vcs api modules is huge and the api itself is being re-factored in many ways, so IMHO it is clear that 6.x-2.x will have a stable in both vcs api and git backend.
#6
agreed
#7
Automatically closed -- issue fixed for 2 weeks with no activity.