Closed RubenHarms closed 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.
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.
That's both okay, as long as we have a pretty stable branch.
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?
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.
I agree that with @MisatoTremor.
For now we have a pretty stable master. I suggest to:
Do you agree @MisatoTremor @Ingannatore?
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.
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.
Update: branch v1.0 is ready, I will add cherry-picked commits as soon as possible.
Replayed on branch v1.0 all relevant commits. v1.0.1 released, already available on packagist. So:
v1.0
master
.Thank you and sorry for a bit of delay.
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.