Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9722 closed Bug (fixed)

Repository ckeditor/ckeditor-release with ready to use releases

Reported by: Piotrek Koszuliński Owned by: Piotrek Koszuliński
Priority: Normal Milestone:
Component: General Version: 4.0
Keywords: Cc:

Description

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

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

Change History (33)

comment:1 Changed 6 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.0.1
Owner: set to Frederico Caldeira Knabben
Status: newassigned

comment:2 Changed 6 years ago by 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]

comment:3 Changed 6 years ago by 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.

Last edited 6 years ago by Jonny N (previous) (diff)

comment:4 in reply to:  3 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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...

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by Jonny N

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

comment:8 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by Jonny N

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

comment:10 Changed 6 years ago by 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.
  1. 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?

comment:11 Changed 6 years ago by 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?!

comment:12 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by Piotrek Koszuliński

Owner: changed from Frederico Caldeira Knabben to Piotrek Koszuliński

comment:15 Changed 6 years ago by 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 .. ?

Last edited 6 years ago by Jonny N (previous) (diff)

comment:16 Changed 6 years ago by Piotrek Koszuliński

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

comment:17 Changed 6 years ago by Jonny N

Great news. Thanks for the update!

comment:18 Changed 6 years ago by Piotrek Koszuliński

Status: assignedreview

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

comment:19 Changed 6 years ago by Jonny N

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

comment:20 Changed 6 years ago by 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?

comment:21 Changed 6 years ago by Frederico Caldeira Knabben

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

comment:22 Changed 6 years ago by Jonny N

Good suggestion Fred!

comment:23 Changed 6 years ago by Piotrek Koszuliński

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

comment:24 Changed 6 years ago by 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.

comment:26 Changed 6 years ago by 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.

comment:27 Changed 6 years ago by Jonny N

Heard anything more back from GitHub support?

comment:28 Changed 6 years ago by 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.

comment:29 Changed 6 years ago by Jonny N

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

comment:30 Changed 6 years ago by Piotrek Koszuliński

@fredck: Any news from Github?

comment:31 Changed 6 years ago by Frederico Caldeira Knabben

Resolution: fixed
Status: reviewclosed

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.

comment:32 Changed 6 years ago by Piotrek Koszuliński

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

comment:33 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy