Where should ZF 3.0 development live?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Where should ZF 3.0 development live?

EvanDotPro
Hi all!

There's been a lot of really great ideas going around on the other thread for ZF3, and a lot of us are already anxious to get started on development.

That brings us to our first question before we can really get any momentum going... Where should we actually be doing ZF3 development?

Here's the options:

A) Start a new ZF3 repository (which will really just be an upstream branch from develop on ZF2, staying in sync with all ZF2 development)
B) Start a 3.0 branch on the existing ZF2 repository on GitHub.
C) Merge ZF1, ZF2, and ZF3 development into a single repository on their appropriate branches.
D) Something else? I'm open to suggestions.

We started on A, as we were eager to get development started, however a couple have voiced concerns about the effects this could have on various aspects of the project (composer, separated issues, etc).

Before I lay out a pro/con list for each option, I'd like to open it up to everyone else to weigh in, as I'm sure there are things I haven't considered. Once we've gathered some feedback, I'll try to post a list of the pros/cons for each idea that we have and we'll try to pick the best option.

While I realize this might get a little opinionated, let's try to keep it more in the spirit of brainstorming rather than debating. 20 e-mails back and forth debating the effects a new repo will have on Composer/Packagist will not help us make a decision. Having 20 unique pros and cons will.

Thanks!

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: Where should ZF 3.0 development live?

Justin Martin
On 13-06-23 08:20 PM, Evan Coury wrote:

> Hi all!
>
> There's been a lot of really great ideas going around on the other
> thread for ZF3, and a lot of us are already anxious to get started on
> development.
>
> That brings us to our first question before we can really get any
> momentum going... Where should we actually be doing ZF3 development?
>
> Here's the options:
>
> A) Start a new ZF3 repository (which will really just be an upstream
> branch from develop on ZF2, staying in sync with all ZF2 development)
> B) Start a 3.0 branch on the existing ZF2 repository on GitHub.
> C) Merge ZF1, ZF2, and ZF3 development into a single repository on
> their appropriate branches.
> D) Something else? I'm open to suggestions.
>
> We started on A, as we were eager to get development started, however
> a couple have voiced concerns about the effects this could have on
> various aspects of the project (composer, separated issues, etc).
>
> Before I lay out a pro/con list for each option, I'd like to open it
> up to everyone else to weigh in, as I'm sure there are things I
> haven't considered. Once we've gathered some feedback, I'll try to
> post a list of the pros/cons for each idea that we have and we'll try
> to pick the best option.
>
> While I realize this might get a little opinionated, let's try to keep
> it more in the spirit of brainstorming rather than debating. 20
> e-mails back and forth debating the effects a new repo will have on
> Composer/Packagist will not help us make a decision. Having 20 unique
> pros and cons will.
>
> Thanks!
>
> --
> Evan Coury
I'd prefer option A. It keeps development of BC-breaking changes
discrete from ZF2, as changes in the develop branch for ZF3 has to be
separate from ZF2. Obviously, that could be resolved by having
zf2-develop, zf3-develop, etc, but that's just moving the issue back one
step.

If ZF3 is even *close* to being as different from ZF2 as ZF2 was from
ZF1, then it makes little sense to maintain them in the same repository.
It wouldn't be sane to cross-pollinate changes directly as merges,
because, depending on the PHP version requirement, the syntax may be
considerably different.
Reply | Threaded
Open this post in threaded view
|

Re: Where should ZF 3.0 development live?

Sascha-Oliver Prolic
In reply to this post by EvanDotPro
Hi all,

C) Merge ZF1, ZF2, and ZF3 development into a single repository on their appropriate branches.

But, please forget about ZF1 for now, it has an own repository, and there are many good reasons for this.

If we compare it with other projects (f.e. the linux kernel) - there is no problem with having different major releases in a single github repository. (And even there we have the example, of leaving out older releases, that are older as git itself).

About issues:
We have some components that do not change much between releases, so issues might apply to all versions, would be easier to resolve them, when you see all of them in one place.

About workflow:
This is important: Especially for the merge team, how would be the workflow to work with issues, how to merge them, how about checking issues doubles? How do you merge to same patch to different branches / repos? What's easier?

About best practices:
What do you think the best practices are? As lots of php developers around the world are looking at the ZF team, they also copy the workflow - we should work with the best tools/workflow, and publish them, help teaching others, how to resolve such problems, too.
Again, ain't it best practice to have all major releases in a single repo? You can find many projects on the web, taking that way. Unfortunatly I couldn't find anything on that topic in the git manual directly.

Best Regards

Sascha-Oliver Prolic



2013/6/24 Evan Coury <[hidden email]>
Hi all!

There's been a lot of really great ideas going around on the other thread for ZF3, and a lot of us are already anxious to get started on development.

That brings us to our first question before we can really get any momentum going... Where should we actually be doing ZF3 development?

Here's the options:

A) Start a new ZF3 repository (which will really just be an upstream branch from develop on ZF2, staying in sync with all ZF2 development)
B) Start a 3.0 branch on the existing ZF2 repository on GitHub.
C) Merge ZF1, ZF2, and ZF3 development into a single repository on their appropriate branches.
D) Something else? I'm open to suggestions.

We started on A, as we were eager to get development started, however a couple have voiced concerns about the effects this could have on various aspects of the project (composer, separated issues, etc).

Before I lay out a pro/con list for each option, I'd like to open it up to everyone else to weigh in, as I'm sure there are things I haven't considered. Once we've gathered some feedback, I'll try to post a list of the pros/cons for each idea that we have and we'll try to pick the best option.

While I realize this might get a little opinionated, let's try to keep it more in the spirit of brainstorming rather than debating. 20 e-mails back and forth debating the effects a new repo will have on Composer/Packagist will not help us make a decision. Having 20 unique pros and cons will.

Thanks!

--
Evan Coury



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: Where should ZF 3.0 development live?

Marco Pivetta
 > C) Merge ZF1, ZF2, and ZF3 development into a single repository on their appropriate branches.

I also prefer this option - it's already weird enough that we have the version number of the project in the project name itself.

The main issues I see with separate repositories are:

 * Duplicate issues - bugs that affect both repositories may be reported on both, or even worse fixed (by accident) only on on one, or reported only on one.
 * Packagist will kind-of hate that
 * It makes it possible to install ZF3 and ZF2 in the same project, with obvious derived chaos from that
 * General panic - people will just think it's like ZF1->ZF2

With ZF1, the problem was moving from SVN to GIT first, so two repositories actually made sense, but here I don't see a reason for that.

The dis-advantage of a single repository is that developers may open pull requests against the wrong branch, but I don't think that's a problem, as I've already told Matthew and Evan.

PRs can be closed and re-opened if something went wrong, and it's always been like that also for other bigger projects (see symfony, I actually think its PR workflow is quite nice!)

So I'd actually love to see following:

 - rename zendframework/zf2 to zendframework/zendframework (github can help with that!)
 - rename branch `develop` to `2.3.x` (or 2.NEXT.x in general) on zendframework/zendframwork
 - use `master` as "current stable release" for hotfixes
 - start a `3.0.x` branch on zendframework/zendframwork

Does this make any sense?

Again, if the problem is people opening pull requests against the wrong branch, I wouldn't try to be over-polite and just ask them to fix their PR instead. Most people will apply bugfixes anyway, and not implement new stuff (which is typically discussed here or on IRC first, and done by more experienced devs)



On 24 June 2013 06:00, Sascha-Oliver Prolic <[hidden email]> wrote:
Hi all,



But, please forget about ZF1 for now, it has an own repository, and there are many good reasons for this.

If we compare it with other projects (f.e. the linux kernel) - there is no problem with having different major releases in a single github repository. (And even there we have the example, of leaving out older releases, that are older as git itself).

About issues:
We have some components that do not change much between releases, so issues might apply to all versions, would be easier to resolve them, when you see all of them in one place.

About workflow:
This is important: Especially for the merge team, how would be the workflow to work with issues, how to merge them, how about checking issues doubles? How do you merge to same patch to different branches / repos? What's easier?

About best practices:
What do you think the best practices are? As lots of php developers around the world are looking at the ZF team, they also copy the workflow - we should work with the best tools/workflow, and publish them, help teaching others, how to resolve such problems, too.
Again, ain't it best practice to have all major releases in a single repo? You can find many projects on the web, taking that way. Unfortunatly I couldn't find anything on that topic in the git manual directly.

Best Regards

Sascha-Oliver Prolic



2013/6/24 Evan Coury <[hidden email]>
Hi all!

There's been a lot of really great ideas going around on the other thread for ZF3, and a lot of us are already anxious to get started on development.

That brings us to our first question before we can really get any momentum going... Where should we actually be doing ZF3 development?

Here's the options:

A) Start a new ZF3 repository (which will really just be an upstream branch from develop on ZF2, staying in sync with all ZF2 development)
B) Start a 3.0 branch on the existing ZF2 repository on GitHub.
C) Merge ZF1, ZF2, and ZF3 development into a single repository on their appropriate branches.
D) Something else? I'm open to suggestions.

We started on A, as we were eager to get development started, however a couple have voiced concerns about the effects this could have on various aspects of the project (composer, separated issues, etc).

Before I lay out a pro/con list for each option, I'd like to open it up to everyone else to weigh in, as I'm sure there are things I haven't considered. Once we've gathered some feedback, I'll try to post a list of the pros/cons for each idea that we have and we'll try to pick the best option.

While I realize this might get a little opinionated, let's try to keep it more in the spirit of brainstorming rather than debating. 20 e-mails back and forth debating the effects a new repo will have on Composer/Packagist will not help us make a decision. Having 20 unique pros and cons will.

Thanks!

--
Evan Coury



--
Sascha-Oliver Prolic

Reply | Threaded
Open this post in threaded view
|

Re: Where should ZF 3.0 development live?

weierophinney
Administrator
In reply to this post by Sascha-Oliver Prolic
On Sun, Jun 23, 2013 at 11:00 PM, Sascha-Oliver Prolic
<[hidden email]> wrote:
> C) Merge ZF1, ZF2, and ZF3 development into a single repository on their
> appropriate branches.
>
> But, please forget about ZF1 for now, it has an own repository, and there
> are many good reasons for this.

Agreed here -- ZF1 has substantially different structure and tagging
needs, and cannot easily be merged into the same repository.
Additionally, due to how we tagged in ZF1, adding it to a combined
repository would hugely inflate its size, making cloning difficult.

<snip>

> About workflow:
> This is important: Especially for the merge team, how would be the workflow
> to work with issues, how to merge them, how about checking issues doubles?
> How do you merge to same patch to different branches / repos? What's easier?

This is actually something we already address -- we adopted git-flow.
This means that any patch merged must also be merged to any newer
branch. If we merge to master, currently that means we must also merge
to develop. If we have ZF3 as a feature branch off of develop,
anything merged to develop must also be merged to that branch.

> About best practices:
> What do you think the best practices are? As lots of php developers around
> the world are looking at the ZF team, they also copy the workflow - we
> should work with the best tools/workflow, and publish them, help teaching
> others, how to resolve such problems, too.
> Again, ain't it best practice to have all major releases in a single repo?
> You can find many projects on the web, taking that way. Unfortunatly I
> couldn't find anything on that topic in the git manual directly.

There's not much information about this out there. The
Composer/Packagist maintainers argue that most projects keep all
versions in the same repo -- but they're looking at a subset of
projects, primarily those created in the last couple of years and
targeting Composer as a primary distribution mechanism, meaning their
assertion is self-selecting.

That said, there's definitely evidence of large projects that work in
a single repo -- the linux kernel, as you already mentioned, and PHP
itself.

So... unable to answer definitively. Regardless, ZF1 cannot really be
part of a combined repository, at least not easily.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: Where should ZF 3.0 development live?

EvanDotPro
On Mon, Jun 24, 2013 at 7:12 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
On Sun, Jun 23, 2013 at 11:00 PM, Sascha-Oliver Prolic
<[hidden email]> wrote:
> C) Merge ZF1, ZF2, and ZF3 development into a single repository on their
> appropriate branches.
>
> But, please forget about ZF1 for now, it has an own repository, and there
> are many good reasons for this.

Agreed here -- ZF1 has substantially different structure and tagging
needs, and cannot easily be merged into the same repository.
Additionally, due to how we tagged in ZF1, adding it to a combined
repository would hugely inflate its size, making cloning difficult.

<snip>

> About workflow:
> This is important: Especially for the merge team, how would be the workflow
> to work with issues, how to merge them, how about checking issues doubles?
> How do you merge to same patch to different branches / repos? What's easier?

This is actually something we already address -- we adopted git-flow.
This means that any patch merged must also be merged to any newer
branch. If we merge to master, currently that means we must also merge
to develop. If we have ZF3 as a feature branch off of develop,
anything merged to develop must also be merged to that branch.

It's worth pointing out that this work-flow for the merge team will be the same no matter what solution we go with, so it should not be a technical factor in the decision. The only difference is which remote we push the 3.x branch up to after a merge.

--
Evan Coury