Add Drupal::VERSION constant update to packaging script [#2544548]

Problem/Motivation

We just rolled beta-14 https://www.drupal.org/node/2544542 which was a quick-ish release to fix a regression in beta 13: https://www.drupal.org/node/2542310

I'd intended to tag the release from the commit that reverted the regression, but realised that the current practice of manually updating the Drupal::VERSION constant before and after tagging prevents this.

Could probably have created a branch, rebased it, pushed it to d.o, then tagged that branch instead, but though I'd open this issue to discuss.

Proposed resolution

When packaging, update the Drupal::VERSION constant, based on the release tag. This would remove the commits for the versions which have to be done every core release, and let us tag releases retrospectively in the future if that need comes up again.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Comment #1

catch

he/him

English

CreditAttribution: catch commented 3 August 2015 at 09:41

Title:	Add Drupal::VERSION constant rename to packaging script	» Add Drupal::VERSION constant update to packaging script
Issue summary:	View changes

Comment #2

drumm

he/him

NY, US

CreditAttribution: drumm at Drupal Association commented 5 August 2015 at 20:47

So this would be updating http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal.php#n84? We could:

Do a PHP parse, update the string, and write the PHP back out. Relatively hard to build, and relatively future-proof.
Or do a simple replace for a magic string. Easy to build, and less future-proof.

This might not be worth it to implement.

The packaging script does update *.info.yml files. Has relying on that been discussed?

Comment #3

catch

he/him

English

CreditAttribution: catch commented 5 August 2015 at 20:51

We don't use the constant that much in core, so could probably move it to YAML entirely.

Only issue is I don't think there's an API for it except the constant - but it'd be a small core issue to add that API and remove the constant which I think we can still do before RC (or it's a very limited change even for a minor release probably).

Comment #4

drumm

he/him

NY, US

CreditAttribution: drumm at Drupal Association commented 5 August 2015 at 20:59

Could even be split into 2 issues. First, add the new API method, it returns the constant's value. Later, the implementation can be switched to not use the constant.