[meta] Blockers to a 6.x-2.0 release

not sure about _the list_, but let's use issue categories and priorities to define it, to have a dynamic list we do not have to update each time.

as a start, IMHO all issues at any category with critical priority are the requirements for a beta1

tagging to avoid forgetting fix this

not a good goal for sprint 4, necessarily.

quoting myself on #484382-5: Get 6.x-2.x branch of vcgit to a beta release:

The only big changes pending I see in VCS API are:

• account re-factor, but hopefully is a minor change here.
• #879600: Meta: introduce an activity stream separate from commit logs, probably not impacting here.
• #879730: Replace the entire VersioncontrolOperation "subsystem" with VersioncontrolCommit, hopefully only function/method naming changes

There are many more thing to do, but IMHO those are required for an alpha1.

We don't need to have a release to launch, much as it pains me.

So, this is a never-ending release :-p

IMHO we just need to make a 6.x-3.x branch, so we can make explicit and visible which issues should be postponed to another branch, instead of trying to deal with all of them together.

sdboyer, webchick: what do you think?

subscribing

Ahh, issue queue manipulation :)

OK, I'm fine with rolling a 6.x-3.x branch for the purpose of delaying issues. But I think we should also try to be diligent about using tags to indicate what's really a blocker.

I forgot to mention we have already a tag for this release blockers: versioncontrol-6.x-2.0-release-blocker, let use it and make this happen soon hopefully.

The number of blockers is less now :-)

So, let me propose a roadmap before 6.x-2.0 release:

alpha2 blockers

A release for testing

• None. Yeah, IMHO it's time to make another alpha release, since a lot of commits are there since alpha1

beta1 blockers

End of API changes

• #1092062: Introduce framework for generic repository history synchronization
• #1045464: Replace all literal $entity->backend instances with $entity->getBackend()
• #998684: Remove the idea of operation label actions
• #606678: remove verbs from interfaces

rc1 blockers

Internal code cleaning.

• #1045496: Stop using 'repo' shorthand in internal variable names and functions
• #1131084: Logic for default plugin selection needs robustification

6.x-2.0 blockers

Tests ready and code standards review.

• #1000870: Inter-entities CRUD operations tests for entities
• #1000874: Behaviour tests for entities
• #997254: [meta] Create tests that exercise CRUD & methods on all our entities
• #1000876: Tests for entity controllers
• #723962: Code standards review

@sdboyer: if you are OK, I will update the summary and create a alpha2 release :-p

Hopefully we can manage versiocontrol on d.o with releases sometime :-)

Just to mention that next week at drupalcon get versioncontrol to a stable release will be my first priority, hopefully more people want to join me about that target.

Well, it really took a while to review and some modifications to integrate completely the generic-reposync branches both here and on versioncontrol_git(most work on vcgit really), but at the end of friday it was done, so, one less big release blocker \o/

BTW I got really bored on the planes back, so I wrote a cgit webviewer plugin for vcgit :-)

beta1 blockers are done now, so I have just created the tag and released it: http://drupal.org/node/1545760

omg, we have such an outdated docs now :-/

I have removed api docs issue after #1291904-1: Update api documentation from release blockers.

So, we are pretty near to start on actually create an official 7.x-1.x branch, so I am removing the related tag.

Remove update api docs issue after http://drupal.org/node/1291904#comment-5913082

Closing this issue in favor of new tags:

• vc-next: Will be done on the next vesrion
• versioncontrol-6.x-2.0-release-blocker: blockers for release, see that tag for a dynamic list of issues.

rm selected label added to the rc1 list