Submit pull-request for .versions

[zimme]

How about adding an option to enable PR to be submitted after successful publications for the changes to .versions file.

This will make it easier to keep a .versions file which is up to date, but it won't solve the problem with it
being in the release tag, because the tag was already set before the PR was submitted.

[splendido]

I'm sorry I'm not following...
What's the problem with the .versions file?

Honestly I still haven't looked at it and have no idea about possibly
implications about maintaining it up to date or not.

Il giorno 20:22 Sab 16/Mag/2015 Simon Fridlund [email protected]
ha scritto:

How about adding an option to enable PR to be submitted after successful
publications for the changes to .versions file.

This will make it easier to keep a .versions file which is up to date,
but it won't solve the problem with it
being in the release tag, because the tag was already set before the PR
was submitted.

—
Reply to this email directly or view it on GitHub
#19.

[zimme]

The .versions file is automatically created/updated by the meteor publish command.

When we use autopublish the command is run on the servers and updates it in it's own clone.

meteorpublish doesn't have write access to the repositories to actually commit the updated .versions file, but it could submit a PR.

[splendido]

Ok, but what's the problem in case the file is missing?

[zimme]

Not really a big problem, but if you check in the .versions file with the version tag 0.5.0 you know that any user which uses that version of the git clone of the package will use the same versions of it's dependencies you used when you published the package.

Making sure you and some other developer are using the same packages and versions on a specific version.

It's not really a problem and the people who actually need this should publish their packages manually instead.

It's just a though.