Rename github.com/silverstripe/sapphire?

[Sam Minnée]

Hi all,

So, a while back, we renamed Sapphire to SilverStripe Framework, and for the most part "sapphire" isn't referenced in the code anymore. Even the packagist package name is silverstripe/framework now, which, all going well, will be most commonly used mechanism by which people access the codebase.

However, the github repository name is still "sapphire". Renaming the repository will be painful, although less so, thanks to packagist/composer holding the github repository name at one further step of indirection.

My recommendation would be to pick a day to do this a couple of months in the future, so people have notice that it's coming. Maybe 1st of March?

What do people think? Seem like a reasonable approach?

I would suggest that we rename it to github.com/silverstripe/silverstripe-framework, as github.com/silverstripe/framework would be too ambiguous once the repo is cloned to another user's account.

Thanks,
Sam

----
Sam Minnée
Chief Executive Officer
SilverStripe Limited

Mobile: 021 311 441
Skype: sam.minnee

[Stevie Mayhew]

Hi Sam,

Thanks for this email explaining the pull request denial.

The reason I submitted that code is because using composer to do the upgrade from a 2.4.7 -> 2.4.9 site fails without a composer directive to change the path of silverstripe/framework to sapphire when installing silverstripe/silverstripe-cms version 2.4.9 which has framework, not sapphire as a dependency.

The following fixes the issue thanks to the work that cams piers did with composer installers.

 "extra": {

            "installer-paths": {

                "sapphire": ["silverstripe/framework"]

            }

    }   

This is a fix for the issue currently, but it would be nicer if we didn't have this issue, which the rename would hopefully fix.

Cheers,

Stevie

--

Stevie Mayhew Developer

Ph. 04 831 5130   heyday.co.nz

Heyday is a digital agency based in Wellington, New Zealand. It employs 30 staff and drives the online presence of brands through insight, ideas, design, delivery and improvement. Clients include Weta, Meridian Energy, GIB, ANZ, Pink Batts, Gallagher Group and Z Energy. Please visit our website for further information.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Zauberfisch]

YES!

my suggestion:

git clone http://.../saphire
git remote rename origin old
git remote add origin http://.../silverstripe-framework.git
git push origin
vim README.md # change text of README.md to say "this is out of date and will be droped on march the first, use http://.../silverstripe-framework.git instead"
git commit -am "sapphire is dead"
git push old

also, I agree that the names should be silverstripe-framework and silverstripe-cms

[Kirk Mayo]

I think renaming it is the best solution another solution would be to create a new Repository called silverstripe-framework and leave sapphire for the time being but this could cause other issues like keeping both repositories in sync

[Sam Minnée]

Yeah, I was a bit mystified by bugfix pull request renaming the project, but perhaps a longer comment would have been better. ;-)

The name of the repository shouldn't affect composer operation.  The underlying issue is that silverstripe/framework must be installed to ./sapphire on 2.4 and ./framework on 3.0.  I don't think that having two different composer package names is the best solution, and I don't think that packagist allows that in any case.  So I think we should have the package name set to silverstripe/framework for all versions, and focus on changing the installation destination for that package.

The fix you describe is included in the 2.4 silverstripe-installer package, but if you're retrofitting an existing 2.4 site (as will be the case for most 2.4 users) this doesn't help.

We could potentially alter Cam Spiers' code for SilverStripeInstaller to do this for us automatically; I'm not sure exactly how it's supposed to work but I assume that the package version number is available when defining the module destination?  Does anyone see any issues with taking that approach?  We'd need to get a PR submitted to https://github.com/composer/installers but I'd hope they'd be forthcoming in merging that.

Specifically, I'm thinking of something like this.  This would be my first commit to Composer itself, so I'd appreciate any critique prior to raising a pull request, if possible.

https://gist.github.com/4506849

Thanks,

Sam

[Sam Minnée]

My preference would be to rename the repo and then recreate the old one, so that PRs are migrated, but yes, keeping an old thing around would be helpful.

Perhaps do what you suggest Feb 1st and drop the old one April ...2nd?

[Zauberfisch]

hmmm, damn it, I haven't thought about the PRs

the problem is, with renaming the repo is, it will loose all its followers (people who starred it)

[Ingo Schommer]

I guess we have to bite the bullet at some point… Feb 1st is as good a date as any.

Here's some related discussion on SO about renaming on github:

http://stackoverflow.com/questions/5751585/change-repo-name-in-github

@Zauberfisch: Do you have any reference regarding "rename will loose all followers"?

Tasks:

- Announce dates on mailinglist

- Rename github.com/silverstripe/sapphire to github.com/silverstripe/silverstripe-framework

- Recreate github.com/silverstripe/sapphire with a big fat warning (incl. on github project description)

- Update packagist remote

- Fix internal TeamCity remotes

- Confirm composer/packagist handle the switchover correctly

- Fix any internal non-composer based dependencies (phing, git submodules)

- Check if Travis registration needs fixing

- Fix doc.ss.org and api.ss.org update scripts

- Fix paths in documentation

- Fix buildtools

- Delete old repo after a grace period (April 2nd)

Did I forget anything?

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/5n0Zb89_f_gJ.

[Simon J Welsh]

The only thing I can think of to check before doing this is that github properly handles pointing existing forks to the right place.

Beyond that, I suggest providing a simple shell script for updating the remotes of framework/sapphire folders. Something like:

#!/bin/bash
for DIR in `find $PWD -type d -name framework -o -name sapphire`
do
cd $DIR
git remote set-url origin git://github.com/silverstripe/silverstripe-framework github.com/silverstripe/sapphire 2> /dev/null
git remote set-url upstream git://github.com/silverstripe/silverstripe-framework github.com/silverstripe/sapphire 2> /dev/null
cd -
done

which can then be run from wherever sites are being stored (such as ~/Sites) and will only change origin or upstream if it contains "github.com/silverstripe/sapphire".

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

---
Simon Welsh
Admin of http://simon.geek.nz/

[Simon J Welsh]

Github is finally providing redirects for renamed repositories (https://github.com/blog/1508-repository-redirects-are-here), so it looks like most of these changes are now optional.

[Sean Harvey]

Great news!

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.

To post to this group, send email to silverst...@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Zauberfisch]

great news indeed,
loosing the link was the main issue, from my point of view there is nothing holding us back now

[Zauberfisch]

also,

i just checked, all sub links (eg sapphire/issues will redirect to framework/issues)
all followers (people who stared the repo) will be kept

[Ingo Schommer]

Github is getting more awesome each day! I've just renamed the repo, ran through the tasks I've mentioned (some still apply),

seems to be going all smoothly. The only adverse effect I could see so far was that Travis CI builds don't redirect, the build counter is reset. 

But that's not really an issue, since historical Travis builds under sapphire are all still available.