Repository ckeditor/ckeditor-release with ready to use releases

[Piotrek Koszuliński]

As requested e.g. here ​https://twitter.com/jonnynott/status/273453091620278275

It'll be possible to add CKEditor as submodule, without any additional steps.

[Frederico Caldeira Knabben]

Proposing the following branch/tag naming convention for the new "ckeditor-releases" repo:

Branches:

• stable/[standard|basic|full]
• latest/[standard|basic|full]
• 4.0.x/[standard|basic|full]

Tags:

• 4.0/[standard|basic|full]

[Jonny N]

Good branch proposal.

I'm imaging the HEAD of 'master' would always be the 'full' package of the latest stable release version, in a production-ready state.

[Piotrek Koszuliński]

Replying to jonnott:

Good branch proposal.

I'm imaging the HEAD of 'master' would always be the 'full' package of the latest stable release version, in a production-ready state.

As we started promoting "standard" preset as the default one I think it should be the one on "master".

Beside that I agree that this branch proposal is good.

[Jonny N]

I'm still working out which 4.0 package I should be using in production anyway - is there some documentation on what's different between the packages? I'm coming from a pretty stock 3.6.x by the way...

[Wiktor Walc]

If you visit ​http://ckeditor.com/builder and select any preset, you'll see the plugins that are included in it.

Also a nice quick way to see the differences would be to download the three packages and check e.g. the replacebyclass.html sample in each of them.

I think it would be nice to provide some clear comparison between the three distributed presets in our documentation.

[Jonny N]

Cool - so which is closest to how 3.6.x came out-the-box?

[Wiktor Walc]

@jonnott The full package contains the biggest number of plugins that were included in V3, but it still does not include everything that 3.6.x had. You should check which features you were using in V3 and select additional plugins from the right column ("Available plugins").

Actually, it might be worth to consider having also a v3 backwards compatible preset. Not sure how many people will be looking for it, however this would make the upgrade path smoother.

[Jonny N]

Any update on when this might be coming? .. really wanna update my production environments to 4.0 ;)

[Jonny N]

I'm happy to get on with creating this repo if there isn't the capacity currently for you guys to undertake it internally.

I don't know if you guys have a paid GitHub account, so either of these approaches could work:

1. Add an empty 'ckeditor-releases' private repo to 'ckeditor' GitHub account. Add myself (jonnott) as a private collaborator. I'll populate it with all the branches/tags/etc outlined above (for v4.0). Then switch the repo to be public.

2. I'll just create the whole thing as a public repo on GitHub, which could then be cloned by yourselves and pushed to your 'ckeditor' GitHub account.

Thoughts?

[Jonny N]

Ok, I got carried away (!) ...

​https://github.com/jonnott/ckeditor-releases/

One thought: would it not be better if the '4.0/[standard|basic|full] were just tags and not branches too? Otherwise, things may get very crazy in time?!

[Jonny N]

I've actually now ditched the '4.0/[full|basic|standard]' branches from my repo, as I don't think they really add anything. The '4.0/[full|basic|standard]' tags effectively do the same job, so it's easier to not try and manage both for each version increment.

[Jonny N]

It moved account .. ​https://github.com/worthers/ckeditor-releases

[Jonny N]

What's happening with this? The repo has been created on the ckeditor github account, but not populated with anything other than a README .. ?

[Piotrek Koszuliński]

We're planning to push releases today or tomorrow. We had to discuss some things.

[Jonny N]

Great news. Thanks for the update!

[Piotrek Koszuliński]

Pushed 9 branches, 3 tags and one commit to master with README file.

[Jonny N]

So is the master branch not going to point the latest stable/standard commit as discussed above?

[Piotrek Koszuliński]

We still have to make decision regarding that. I'm hesitating between two options - leaving it as it is now, to force everyone to consciously pick suitable branch. Or to point master to stable/standard.

Fred, what's your opinion?

[Frederico Caldeira Knabben]

I would remove master and make stable/standard the default branch.

[Jonny N]

Good suggestion Fred!

[Piotrek Koszuliński]

Good idea. Go ahead Fred, cause I think that I don't have rights to do so :).

[Frederico Caldeira Knabben]

I've just tried making this change. GitHub makes it easy to set the default branch. I've chosen "stable/standard". But then a plain git clone brings me the "4.0.x/standard" branch :?

I've reverted it to master for now, to avoid confusion, and sent a message to GitHub. Let's see if this is a bug on their side of if it is just git and we'll have to think about something different.

I'll keep the ticket updated.

[Jonny N]

Could this be of help?

​http://www.kernel.org/pub/software/scm/git/docs/git-symbolic-ref.html

[Frederico Caldeira Knabben]

I believe this would help only locally. Even though, Im still confused on how it could help.

I've just received the reply from GitHub... of course the didn't ready my message and said something totally unrelated. So I've sent a screenshot that should be able to make it clear. To avoid their further confusion, I've left the configuration on "stable/standard", so anyone trying to clone the repo will take "4.0.x/standard" for now, unfortunately.

I hope to have more news soon.

[Jonny N]

Heard anything more back from GitHub support?

[Frederico Caldeira Knabben]

Nothing for now. It took them 3 days for their first reply, so I hope we'll have something either today or tomorrow.

[Jonny N]

@Reinmar Thanks for your ongoing work on the releases repo! Much appreciated ;)

[Piotrek Koszuliński]

@fredck: Any news from Github?

[Frederico Caldeira Knabben]

Yes, I got some news from GitHub.

That's not their fault. That's just the way git does things.

In a fresh clone, HEAD is not sent to your computer as a branch name, but rather as a commit SHA hash. Your local git then looks up that SHA in a table of refs, which is stored alphabetically, and uses the first match. There is no way to tell it to use something else, by default.

So, sincerely, it looks like there is little we could do about it here. The only recommendation is using "-b" on clone to specify the branch to use.

[Piotrek Koszuliński]

We can still make master == latest/standard. Wouldn't that be enough?

[Frederico Caldeira Knabben]

Well... I think that git will get master first, if it matches other branches, so it may be a way for it. Still I think this also deserves a ticket at the git side as well.

@Reinmar, please feel free to go ahead with it.