Split repositories for new version?

[klaussilveira]

There's a major refactoring of GitList ahead, which would mean the first major release: 1.0. However, i'm not sure if i'll even start with the current code, or just start from scratch and slowly backport stuff from the legacy codebase.

In order to continue, i need some feedback from the community: should we split the repo into two, or keep a legacy branch, and a new master for 1.0? Or the contrary (develop is 1.0, master is legacy until 1.0 is released)?

[garygreen]

Please keep under the same repository. I dislike splitting into two separate repositories, it can be very confusing and dilute the community.

You can always start from scratch, just create a new orphan branch and, as you say, backport some stuff as you go.

+1 to develop is 1.0, master is legacy until 1.0 is released

[erez-o]

Since repository split can dilute the community I agree with Gari.

[DannyvdSluijs]

Lets keep the repository the same, as the requirements can shift between the milestones, and in basic this is the same project.
Cant we create a new (feature) branch to do the major refactoring which wont halt any PR's for fixing any current or new issues. Klaus can take his time to do the refactoring. And in time master can be forcevly merged with the feature branch.

This enables the community to move forward with bugfixing or adding unit tests which i've did a pull request for. And when Klaus is ready make the shift.

[dkozel]

My votes.

Keep the same repository. I imagine the goal is to completely supersede the 0.x release with the 1.x so it is counterproductive to provide an easy way of accessing the old code after the new release.

Keep development for the 1.x release happening on a new branch which is merges into master at the time of release. That way people wanting the latest "stable" release just keep running the master and it is easy for smaller patches to be contributed to the current code base. The development branch can diverge, drop features, and make whatever changes are needed during the major rework.

[garygreen]

@klaussilveira For the full recode, have you had any thoughts on what framework it'll be written in? Will it still be silex? I'd personally +1 for Laravel, or even Lumen.

[klaussilveira]

@garygreen, the framework will still be Silex. But the code will be much more framework-agnostic. Just controllers, no hard dependencies or service location. We just need a router and a DIC, after all, so, doesn't really matter what we end up using.

The target version, btw, is 5.4.

[garygreen]

@klaussilveira well I'll leave the recode fully in your hands, as you have a pretty good idea how it will all work in your mind.

I would opt for Laravel personally, as Silex or Lumen are more designed for micro-services whereas gitlist is a full blown app. Plus it would really benefit from eloquent ORM and queue workers alone (which would be awesome to use for the caching layer, scanning for new or changed repositories in the background, or offload to queue worker once page is requested etc). Not sure how easy that kind of thing is to do in Silex but it's toddler stuff in Laravel.

Out of interest how do you envisage the cache layer working in the recode exactly?

[klaussilveira]

We can achieve that by using independent components from the community, such as libraries from The PHP League, Aura, or Symfony. No need to rely on a monolithic solution. Caching can be done, for example, with https://github.com/tedious/Stash or https://github.com/LinioIT/cache, with a thin abstraction layer on GitList.

By using a microframework, and carefully choosing the amount of contact areas, it's easy to design a framework-agnostic architecture which GitList can heavily depend on. If, in the future, Silex is too slow or does not meet the requirements of the application, we can easily switch to a custom-made solution or similar alternatives, like Slim or Lumen.

The reasoning behind not choosing Lumen at first it because the official documentation suggest the usage of bad practices that force you into staying at the framework: using helpers like response(), view() and etc, extending the base controller, etc. Those are the same bad practices that were recommended by Silex at the beginning of the framework, that ended up causing lot's of problems in the maintainability of GitList.

ps.: Regarding the ORM, i still don't have any plans of adding any kind of persistence layer on GitList other than raw filesystem. If a plugin wants to, that's a whole different story. But GitList itself would not rely on persistence of any kind, other than the filesystem for plain configuration. We don't want to be GitHub or GitLab, there are many other projects with this goal already.

[garygreen]

I see your points although I don't fully agree that Lumen ties you into the framework simply with it's helper functions (it's more a style choice, there's nothing stopping you using the underlining class that it resolves to). How much you want to tie into the framework is really up to you, and if your not tied into the framework then your tied into another package from the community. Either way, your tied in. Only way around is to create an abstraction which you can do with or without a framework.

Moving forwards, maybe we should build up a list of features/refactoring ideas for v1 and then a list of packages that will help aid, like caching layer, etc. At the moment I'm still kind of unclear why a full recode is needed (as opose to fixing issues in v0.*) so if we have a full list of specific ideas and solutions that would paint a much clearer picture. The things I can think of straight away:

• Caching layer (for repositories listing, recent commits log?, stats?)
• Fix various issues with special chars in repository names (although this can be fixed in 0.*)
• Plugin architecture
• ???

[alehaa]

As discussed in #725 the proposed refactoring of GitList will have less features, so some of the users may like to stay at a version based on the current code, thus I'd opt for a separate repository that's in the same namespace like the "old GitList", e.g. two repositories in an organization. Otherwise this could end in a nightmare, if users file issues for the new version in the old repository and vice versa.