Backport "Set full version in Drupal .info files"

[ergonlogic]

I think we'd agreed that we'd manage backports and such via issues and pull requests here. Please set me straight, if I misunderstood.

I just had a small pull request (civicrm/civicrm-core#645) merged into upstream CiviCRM master, and have requested that it be back-ported to 4.3 (https://github.com/civicrm/civicrm-core/issues/661). I'd like to do the same for 4.2. This would allow better consistency in Aegir's support of CiviCRM, and a simplification of that code.

Normally, I would have submitted this as a pull request, but I don't see the 'distmaker' directory in the source tree. From what I can tell, it was in 4.2 SVN (http://svn.civicrm.org/civicrm/branches/v4.2/), but it's also missing from Eileen's repo (https://github.com/fuzionnz/civicrm).

This all pre-dates my involvement with core, so I'm in the dark. I seem to recall hearing mention that we'd have to back-port these scripts. If that's the case, I've just been working with them, and would be happy to help out there.

[emphanos]

Hi Christopher,

The distmaker script which was used for SVN is no longer used for releases
that are being pulled from github directly. There is a new set of
distribution tools that Tim Otten has written that creates a release based
on the split github repos.

Young-Jin

On Mon, May 6, 2013 at 2:22 PM, Christopher Gervais <
[email protected]> wrote:

I think we'd agreed that we'd manage backports and such via issues and
pull requests here. Please set me straight, if I misunderstood.

I just had a small pull request (civicrm/civicrm-core#645civicrm/civicrm-core#645)
merged into upstream CiviCRM master, and have requested that it be
back-ported to 4.3 (civicrm/civicrm-core#661https://github.com/civicrm/civicrm-core/issues/661).
I'd like to do the same for 4.2. This would allow better consistency in
Aegir's support of CiviCRM, and a simplification of that code.

Normally, I would have submitted this as a pull request, but I don't see
the 'distmaker' directory in the source tree. From what I can tell, it was
in 4.2 SVN (http://svn.civicrm.org/civicrm/branches/v4.2/), but it's also
missing from Eileen's repo (https://github.com/fuzionnz/civicrm).

This all pre-dates my involvement with core, so I'm in the dark. I seem to
recall hearing mention that we'd have to back-port these scripts. If that's
the case, I've just been working with them, and would be happy to help out
there.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[ergonlogic]

Right, these: https://github.com/civicrm/civicrm-core/tree/master/distmaker

Should I submit a pull-request to include these? Is that work already underway? Or is there a different set of tools planned for 4.2 releases? I seem to recall hearing something about pushing changes into SVN, and then building releases from there... Having looked at the newer distmaker scripts, I think there's an argument to be made for using them.

[emphanos]

Hi Christopher,

In our discussions with Mathieu, Tim and Nicolas, we decided to use the
same process that's currently in place for 4.3.x releases i.e. getting code
from github (thus the github.com/civicrm42 repos) and skip SVN related
checkins altogether.

Young-Jin

On Mon, May 6, 2013 at 3:24 PM, Christopher Gervais <
[email protected]> wrote:

Right, these:
https://github.com/civicrm/civicrm-core/tree/master/distmaker

Should I submit a pull-request to include these? Is that work already
underway? Or is there a different set of tools planned for 4.2 releases? I
seem to recall hearing something about pushing changes into SVN, and then
building releases from there... Having looked at the newer distmaker
scripts, I think there's an argument to be made for using them.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-17505744
.

[nganivet]

Tim worked on backporting the 4.3 release scripts to 4.2, but I do not know where the result from this effort is.
Chris – the patch you made on 4.3 Drupal should therefore be trivial to backport since it is on the same base.

Nicolas Ganivet | Principal | [email protected]
cividesk | +1 (866) 670-7165 | www.cividesk.com

From: Emphanos LLC [mailto:[email protected]]
Sent: Monday, May 06, 2013 2:57 PM
To: CiviCRM42/civicrm42-core
Subject: Re: [civicrm42-core] Backport "Set full version in Drupal .info files" (#1)

Hi Christopher,

In our discussions with Mathieu, Tim and Nicolas, we decided to use the
same process that's currently in place for 4.3.x releases i.e. getting code
from github (thus the github.com/civicrm42 repos) and skip SVN related
checkins altogether.

Young-Jin

On Mon, May 6, 2013 at 3:24 PM, Christopher Gervais <
[email protected]> wrote:

Right, these:
https://github.com/civicrm/civicrm-core/tree/master/distmaker

Should I submit a pull-request to include these? Is that work already
underway? Or is there a different set of tools planned for 4.2 releases? I
seem to recall hearing something about pushing changes into SVN, and then
building releases from there... Having looked at the newer distmaker
scripts, I think there's an argument to be made for using them.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-17505744
.

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

[emphanos]

Correction to what Nicolas was saying in the previous email:

There are release scripts for 4.3. that work with github. Tim has not
backported these scripts to 4.2. If a patch was made on the 4.3. release
scripts we will "inherit" those without modification for use on
github.com/civicrm42, there is no backporting necessary.

Young-Jin

On Mon, May 6, 2013 at 5:09 PM, cividesk [email protected] wrote:

Tim worked on backporting the 4.3 release scripts to 4.2, but I do not
know where the result from this effort is.
Chris – the patch you made on 4.3 Drupal should therefore be trivial to
backport since it is on the same base.

Nicolas Ganivet | Principal | [email protected]
cividesk | +1 (866) 670-7165 | www.cividesk.com

From: Emphanos LLC [mailto:[email protected]]
Sent: Monday, May 06, 2013 2:57 PM
To: CiviCRM42/civicrm42-core
Subject: Re: [civicrm42-core] Backport "Set full version in Drupal .info
files" (#1)

Hi Christopher,

In our discussions with Mathieu, Tim and Nicolas, we decided to use the
same process that's currently in place for 4.3.x releases i.e. getting
code
from github (thus the github.com/civicrm42 repos) and skip SVN related
checkins altogether.

Young-Jin

On Mon, May 6, 2013 at 3:24 PM, Christopher Gervais <
[email protected]> wrote:

Right, these:
https://github.com/civicrm/civicrm-core/tree/master/distmaker

Should I submit a pull-request to include these? Is that work already
underway? Or is there a different set of tools planned for 4.2 releases?
I
seem to recall hearing something about pushing changes into SVN, and
then
building releases from there... Having looked at the newer distmaker
scripts, I think there's an argument to be made for using them.

—
Reply to this email directly or view it on GitHub<
https://github.com/CiviCRM42/civicrm42-core/issues/1#issuecomment-17505744>

.

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

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-17511462
.

[ergonlogic]

While we probably can run the distmaker.sh script from a 4.3 (or master) repo as is, and just point to a 4.2 source tree, I'm not sure it's the best solution. Also, has anyone actually tested this yet? I don't think any changes would be required to back-port these scripts, and having local copies in the 4.2 repo would insulate us from potentially disruptive upstream changes.

[ergonlogic]

A recent test of running the buildmaker.sh script failed, as I documented in issue #3. I also started a wiki page to document the Release process.

[mlutfy]

I did two fixes on dists/drupal_php5.sh and dists/drupal6_php5.sh:

• use the $TRG directory for the sed, because the files are copied in a temporary directory before tar (and avoid changing files in the git repo)
• changed version regexp to .*, not [1-9.], since we need to match 0 too, and seemed safer to glob everything.

This needs to be forward ported to 4.3 / master.