At the moment, given how the marketplace rejects duplicate ID's, the whole usage of overriding extension Id, Tag, Publisher is broken in this extension when the extension contains build tasks.

Experimental branch pushed to:
https://github.com/Microsoft/vsts-extension-build-release-tasks/tree/features/uuidv5

@bryanmacfarlane, @trevorsg, @ericsciple, @willsmythe
Does this make sense to you? I'm using uuidv5 to generate a unique id for each task based on:

• Publisher
• ExtensionId
• ExtensionTag (which is appended to the Id)
• TaskName

Optionally it could use the existing UUID of the task as an input into the generation as well.

        let extensionNs = uuidv5("null", `${ns.Publisher}.${ns.ExtensionId}`, true);
        extensionNs     = uuidv5(extensionNs, manifestJSON.id, true);
        manifestJSON.id = uuidv5(extensionNs, manifestJSON.name, false);

The current implementation is hacked in, only works when building from manifest and only when Publisher and ExtensionId are specified as overrides in the tasks configuration. So it needs refactoring to work. It could also be something that tfx could handle for me instead...

This way if someone wants to fork my repo and wants to publish under their own publisher, it will automatically generate unique id's for that publisher and will prevent collisions.

I'd like to create full DevOps experience for my own extension and I stop on IDs duplication, so, it will be nice to have feature for generate and override tasks ID.

Got this from the marketplace team:

The marketplace changes are deployed now. You should be able to able to now publish private extensions without having to change the task id.

This would suggest we won't need to regenerate UUID's, which is a good thing!

There is another case which is hard to handle. When you have multiple build tasks in your extension, you can use the "Update Task version" switch to update the version of the tasks within the extension. But what if you want to update the major number of one of the tasks (for a breaking change)? You could update the major version of the entire extension, but then all the tasks would have their major versions revved.

It would be great if the Create/Publish extension tasks had an option to just update the rev of the build tasks within the extension. That way I could specify 1.0.1 for some tasks and 2.0.1 for other tasks - when the build runs, it will update to 1.0.x and 2.0.x respectively (using the build $rev variable).

Currently not needed. Closing.