dart-lang / pub-dev

The pub.dev website
https://pub.dev
BSD 3-Clause "New" or "Revised" License
789 stars 146 forks source link

Provide two phase publish action to pub.dev #4489

Open bsutton opened 3 years ago

bsutton commented 3 years ago

pub.dev has a sensible policy of making each 'publish' action a permanent version.

This makes a lot of sense for the broader ecosystem.

The implementation of this feature however causes problems.

I have a fairly complex build environment which also automates the publish actions.

The result is a failure in the build can result in a package being published which I really didn't want published.

This is particularly problematic when I need to publish a set of related packages that depend on a base package.

During development I use a local path in pubspec.yaml to refer to the latest version of the base package.

When I go to deploy my set of packages they can't be published using a local path. The result is I must first publish the base package, update the shared path to point to the pub.dev version and then release the remaining packages.

The result is that I often publish the base package but the dependant packages aren't published. By itself the base package is useless.

This problem could be solved by having a two part publish action.

The first action would publish the package but only make it visible to the author. This would then allow me to publish the dependant packages. I would then run a second command that made the package public. It would be nice to have an option to delete the 'author' only version of the package.

sigurdm commented 3 years ago

Yes - we have been considering something in this direction. We call it "Staged publishing".

There is quite some design span - and we don't have a timeline for this yet.

https://github.com/dart-lang/pub-dev/issues/3650 sounds like a similar idea.

winksaville commented 1 year ago

Any progress on design and implementation?

isoos commented 1 year ago

@winksaville: We think that automated publishing with github actions and service accounts gives about 80-90% of the benefits of staged publishing. Maybe a missing peace would be a github workflow that runs pana and asks for publishing approval with presenting the pana results to the approver. This is not there yet, as we need to change pana to accommodate that workflow (and also be 100% identical that we use on pub.dev).