search

gibilogic / tinymce-bundle

Bundle for connecting TinyMCE (WYSIWYG editor) to your Symfony2 project
7 stars 5 forks source link

New branch #9

Closed RubenHarms closed 9 years ago

RubenHarms commented 9 years ago

I suggest to create a new branch for a stable symlink function. Other pull requests could be merged on the master, untill we've a stable version with workable symlink functionality. To avoid other problems.

Ingannatore commented 9 years ago

You're totally right; something like 1.1-dev? Maybe we should also alias the dev-master version to that new branch.

MisatoTremor commented 9 years ago

I personally like the way it's done by Symfony etc.: Having the "bleeding edge" development in master and create branches for minor versions and create releases from them.

RubenHarms commented 9 years ago

That's both okay, as long as we have a pretty stable branch.

Ingannatore commented 9 years ago

The idea behind is to have a clean master where other contributors can make pull requests without the fear of sudden changes; @MisatoTremor could you make a pratical example using our 1.1 milestone as base?

MisatoTremor commented 9 years ago

tl;dr:

I think a master branch should never be considered as stable as it's per definition the one pointing to the most recent development. But version branches can help to circumvent the sudden change problem. So the way now would be to branch 1.1 from master and create PRs regarding it's milestone issue(s) against the 1.1 branch instead of master. When a PR is considered working and merged, the branch changes can also be merged into any higher maintained version branch and finally into master. Anyone who wants to create a PR for an bug in a maintained version should do so against that versions branch. Any new features should always be created against the most current development version.

It might be a good idea to create a 1.0 branch form the latest commit before the outsourced TinyMCE commits (6ee866d) as the current stable branch, so people can add any bugfixes there.

RubenHarms commented 9 years ago

I agree that with @MisatoTremor.

RubenHarms commented 9 years ago

For now we have a pretty stable master. I suggest to:

Do you agree @MisatoTremor @Ingannatore?

MisatoTremor commented 9 years ago

That commit already includes the outsourced TinyMCE which might still have issues with pathing.

I therefor aimed for 6ee866d as this only contains the composer changes necessary to use this forks version as dependency, making this as stable as the original repo currently is.

The outsourcing would then be part of a new version branch, where development of this and other features takes place.

zanardigit commented 9 years ago

Although I can understand the reasoning, I don't think this project justify the existence of permanent master and development branches. The current situation is an exception because we had lots of things to do / fix from previous project and because we had unexpected issues in outsourcing TinyMCE.

As a temporary solution, I will produce a v1.0.0 branch from the mentioned commit (TinyMCE included), cherry-pick useful commits from master. and produce a new v1.0.1 release. This can be repeated if required.

Once master is stable again to produce a release, v1.0.0 branch will be dropped and from then on, we'll try to keep master as stable as possible.

zanardigit commented 9 years ago

Update: branch v1.0 is ready, I will add cherry-picked commits as soon as possible.

zanardigit commented 9 years ago

Replayed on branch v1.0 all relevant commits. v1.0.1 released, already available on packagist. So:

Thank you and sorry for a bit of delay.