Delete pico-1.1 branch

[nitrix]

I love how everything's becoming very tidy and clean.
Like, I noticed how the releases all got proper tags and stuff :]

Could we remove the old pico-1.1 branch too?

Also would be nice to have a develop branch and follow some form of GitFlow flow to ease development and encourage contributions.

[PhrozenByte]

Good point 👍

I've deleted all merged/obsolete branches, including pico-1.1 and gh-pages.

We won't introduce a develop branch. Please refer to the "Branching" section of our CONTRIBUTING.md for details. Due to the fact that we officially don't support Pico installations using the picocms/Pico repo as a basis since Pico 2.0 anyway, there's simply no reason to ensure that master is a stable version of Pico. We furthermore don't support multiple stable releases at a time. GitFlow would be a bit exaggerated here... 😉

[nitrix]

Thanks, I'll close the task.

Just to inform you quickly though:

we officially don't support Pico installations using the picocms/Pico repo as a basis since Pico 2.0 anyway, there's simply no reason to ensure that master is a stable version of Pico

That's fair, even though people will probably assume master to be stable, since naming your branch master is already a convention of its own in that regard.

Unfortunately, I could see the documentation be misleading:

the master branch always consists of a deployable (but not necessarily deployed) version of Pico.

Whatever that means. As a user, I'd totally read this as the master branch being stable and deployable to production.

I'm guessing your intention here was to say that it should always be in a healthy state for development purposes, but not necessarily tested well enough to be production ready. And there, you've basically re-invented the develop branch, excepted you've confused everyone along the way.

GitFlow would be a bit exaggerated here

Is it? You already want the semantics of a healthy develop branch for development, you already have feature/ and fix/ branches schemes, you tag your releases and your documentation claims that the master branch is deployable. That's literally GitFlow, except each part is a little wrong.

Let me insist, because you've been fumbling around with a makeshift strategy for the past months. I had to follow the work on a branched named pico-1.1 for version 2.0, betas were tarballs on two different repos, there were 3 different threads for version 2.0, each being massive TODO-lists.

What if people want to use your project? Or, in my case, contribute? Can't. I know I tried. It's an organizational mess. Thankfully, it's getting better and I hope my criticism can contribute improving it further... 😉

[PhrozenByte]

I don't think that Pico's branching concept is confusing, I rather think that you're just so used to GitFlow, that you're (falsely) trying to apply its principles to any other project. Using release and feature branches is way older than GitFlow, it's even older than Git itself. Same for what master is (it's just Git's default branch, no more or less, what "default" means depends on the project; btw: AFAIK there's not a single reference to master without "master isn't for production"). Since GitFlow is no "new" approach, but rather a composition of widely known principles taken to the extreme, you'll always find resemblances - what might boost the false impression Pico's branching concept might be similar to GitFlow. It isn't.

Moving to a fully Composer-compatible environment was a massive change concerning Pico's project structure. This was a unsatisfying situation for sure and it took way to long (due to very limited time). The simple reason why the branch was named pico-1.1 and not pico-2.0 is because you can't rename a branch with a open PR on GitHub.

Im not sure what you mean by "betas were tarballs on two different repos". What two repos? You could install Pico 2.0 using Composer from the start, I simply didn't document it anywhere. We're encouraging people to ask if something is unclear, we're lacking documentation in general. I simply don't have time for it.

I'm not sure which "3 different threads for version 2.0" you mean; there was #334 (code) and picocms/picocms.github.io#18 (docs). Both focused on completely different things. It's true that both were massive TODO-lists. That's because they started the same way as #317.

Again, we're encouraging people to ask if something is unclear and to give feedback. This is the first time I'm hearing that you want to contribute to Pico. Why didn't you simply ask? I'm happy to answer any question. However, I won't document things if there's not even a small hint that one might actually want to read it...

So: What is unclear or missing, so that we enable you to contribute to Pico? I'm really looking forward to any help! 👍