3.4.0 current status

[neo22s]

Hello!

Hope this is not repetitive I couldn't find this discussion anywhere else.

• What are the plans for 3.4?
• what's the current status?
• how can we help to move it forward?

Thanks!

Release and branching plan (thanks to @enov)

• Release 3.3.5
• Review and restructure outstanding Github issues and PRs
  • Restructure milestones, rename 3.4 milestone to 4.0
  • Review and close all issues and PRs that are no more relevant
  • closing any that are redundant, out of date or not of high enough quality to merge
  • merging any bugfixes that are backwards compatible so that they can be in 3.3 and 4.0
  • merging any breaking changes that are close enough to complete to go with the upcoming breaking 4.0 release
  • assigning any longer-term breaking changes (including issues that nobody's started working on yet) to a new 5.0 milestone
• Merge 3.3/develop to 3.4/develop
• Create a master branch based on 3.4/develop
• Delete all 3.*/develop branches
• Delete all other unwanted branches
• In the master branch fix all occurrence of 3.4 with 4.0
• Fix composer required versions in master
• Update kohana/koharness script for new branch naming structure
• Update Travis scripts to make the tests pass
• Write new CONTRIBUTING guidelines reflecting branching changes
• Do above steps for all Kohana modules
• Create a 4.0.x branch based on the master branch
• Change the version and the codename on a separate commit in that branch
• Release by tagging v4.0.0-beta1
• Update kohana-ci scripts for new branch naming structure (optional)
• Do above steps for Kohana modules that have BC braking changes, no need to newly release those who are not changed

[enov]

There were few features that I was going to propose, like namespacing the base classes, adding some features to the routes, etc... But we already have pretty good features already, as v3.4 is composer-first and psr-3 compliant.

I think #524 is a stumbling block for v3.4 and needs to be addressed. That's why I created #656 and requested comments.

I think @acoulton is in favor of releasing earliest possible. He expressed such opinion here.

cc @rjd22 @acoulton

[Ikke]

I think it makes sense to make a smaller release. The longer you wait with releasing, the less relevant such an update will probably be.

[neo22s]

@Ikke agree, small release with few improvements and PHP 7 compatible would be the best.

I also have many suggestions for the site...

• if we launch KO 3.4 we should take a look to the landing: http://kohanaframework.org/
• We can host the site on github pages
• Host the documentation on something similar to https://readthedocs.org/ or again github pages, is what we use on open classifieds see http://docs.yclas.com/
• http://dev.kohanaframework.org/projects/kohana3/issues is not working and should point directly to github.
• All should be in github in my opinion its free and we get great tools
• http://kohana-modules.com/ should some how be part or linked to the site.

[acoulton]

Is #524 definitely required for 3.4? What's broken without it? If it's just that it's a breaking change I don't see why we can't defer it. I think multiple small (breaking) releases is better than one with a huge list of changes.

I think we should lock and release 3.4 asap. Also I think we should release it as 4.0 and follow semver properly from now on, it makes using composer much easier.

I'd also be in favour of changing the branch structure at this point to just have 4.0.x-dev etc and no longer any /develop /master branch - there's no need for a "stable" branch if we're tagging releases properly and it complicates contributing.

[neo22s]

#524 should not be a stopper to release a new version and move the project forward, at least my opinion.

I agree with 4.0 new semserv and also with the branches.

Sounds all good!

[enov]

#524 should not be a stopper to release a new version and move the project forward, at least my opinion.

I have mistakenly thought that the modules were loaded from bottom-to-top in version 3.4. That's why I made #656 to fix the routes.

Since they are loaded from top-to-bottom, and moreover, since it was already that way in 3.3, it is possible to mark #524 as a known issue.

[sigma-technology]

Just wanted to say I've been following the "revival" of Kohana and wanted to convey my personal thanks to @neo22s for picking up the mantle (sorry if I've missed others out). We have used Kohana over the past 3 years to develop an advanced HMVC application, and I was gutted when shadowhand seemed to have given up on it. It is a fantastic framework and the HMVC functionality seems to be unparalleled.

I will contribute where I can, but again thank you for continuing to develop Kohana for PHP7 etc. I would be happy to add to the documentation at some point as I feel this is a major blocker for new users.

Onwards and upwards!

[neo22s]

@SigmaTec thanks, but many more are working hard and much better technically. I am just a pain in the ass since I can not let go of KO since all my business relays on this ;)

So what do we do next? should we set a date for kohana 4? should we create a milestone and add the correct issues to the milestone?

[sigma-technology]

@neo22s Exactly the same situation here - all our eggs are in one basket, and that basket is propped up by Kohana. It would be a major problem for us if the framework "died". It definitely is worth our collective time and effort to make it great(er).

#524 isn't a problem for us right now, and we don't really have any issues with the latest master. It would be nice to be able to use PHP7 but we're in no major rush. So I'd just be happy to see it progressing in any way whatsoever. Huge thanks to everyone.

[enov]

Yeah, it seems that we need to release at this point. I'll close #656 for the time being.

[enov]

@acoulton @rjd22 is there anything holding the release of a new version? Should I attempt to release a beta?

[acoulton]

@enov that would be great, I don't think there's anything holding it - I was going to try and find time to do a beta but haven't had a chance. Are we going to call it 4.0?

[enov]

I don't mind calling it 4.0, I think it would be nicer to follow semver all the way from that point. Are we going to have a newer git structure for Kohana repos? I think there was an issue about it somewhere.

[enov]

Yeah, @acoulton #660 (comment) here's your comment suggesting a new branch structure, it's on this same tread 😅

[rjd22]

@acoulton @enov I would vote for semver in combination with releases and no versioning in branch names anymore from here on.

[neo22s]

@rjd22 yes releases with tags seems the easier, is what we do at open classifieds.

Lets simplify all the process as much as possible so people can contribute more.

What do we do ? how can we move this forward? thanks

[enov]

Thanks @rjd22 @neo22s. I will attempt to put down a detailed plan here, in this thread, for all the steps we need to take for a new release and a simplified git branching. We can then discuss these steps before any implementation.

[enov]

~ edited by @acoulton to move @enov's to-do list up to the issue description to make it more obvious ~

[neo22s]

@enov sounds good!

Few questions:

1. 3.3.5 its something you have prepared? there's any important bug?
2. Do we need to have each module in a separate repo? at the end is a mess to have so many repos around and makes it difficult to keep them updated....why not just 1? I am sure there's disadvantages, but the question here is, there's more advantages?

[enov]

3.3.5 should be a maintenance release the merged bugfixes:

https://github.com/kohana/core/compare/3.3/develop

Symfony has one repo, and has modules as read-only repos. I have no idea the advantages/disadvantages and how we can do that.

Note that this is preliminary plan... As we discuss, we can add/edit/delete things.

Feel free to edit it :) and maybe add a comment for the things you have changed.

Cheers! 😘

[enov]

I have added two steps below release 3.3.5

• Review and close all issues and PRs that are no more relevant
• Restructure milestones, rename 3.4 milestone to 4.0

[enov]

Added a step:

• Write new CONTRIBUTING guidelines reflecting branching changes

[neo22s]

I suggest to move all the modules then to the same repo...so we use only 1 repo, 1 issue , 1 milestone, 1 release, 1 unique place for PR..... will make it lot easier to manage in time efficiency I mean.

---

Another subject:

Can we also please do a new home / website? could be hosted at github using jekyll...

I mean just a landing, the one we have looks from early 2010... not really professional.

I am more than happy to buy a template (or use an open source one) do the copies and pay a designer to do the last changes.

The home should not have more than:

• features
• showcase
• links to github, download, issues, kohana-modules.com, documentation, forum..

Basically what has now xD I see got more simplified xD

[sigma-technology]

Great to see things moving forward guys. I'd be more than happy to get my team to design and host a new website for Kohana (and maybe a new logo?) - it's the least I can do. Hopefully it will help to give it a new lease of life! We have developed a CMS using Kohana as the foundation, so I could set up user accounts for everyone if it is of interest. I won't take offense if the answer is no :) Check out http://www.firepineapple.com for examples of our work.

[rjd22]

@enov what we also could do for branching is follow how symfony does it. Have a master branch for development and make version number branches for when a minor version gets released.

So:

Master
4.0
4.1
4.2
5.0

This will make contributing to kohana way easier. And still enable us to fix bugs in minor versions.

[acoulton]

Can we move discussion of a new website to an issue of its own to avoid cluttering this thread?

@enov I've added updating the koharness script to your list

I suggest using Composer's standard default branch naming pattern:

• We just create a 4.0.x branch and remove all others.
• Composer will automatically maintain a 4.0@dev version from this branch. If it ever gets deleted then 4.0@dev will just resolve to the highest 4.0 release tag
• If we want to fix a bug in an older version we can create a 3.5.x branch at the time, and then delete it when we release 3.6 (or 3.5.1 or whatever).
• When we start work on a BC-breaking feature, we start a 5.0.x branch.
• We set the github default branch to whatever we want people to contribute to by default, and change it over time

There's no need to have the old version branches around if they are identical to a release tag. it's trivial to create the branch later.

I think discussion of 1 overall repo should probably also be in a separate thread, but I'm a strong 👎 - downsides off the top of my head:

• We'd need subtree splits like symfony for composer packages, and would need to set up (and probably host) to maintain them
• I find it much harder (eg with symfony) to contribute a fix as a package user - you only have that one package on disk, you have to go find the parent repo, clone it, work out where in it to find the code you already had, possibly pull in dependencies you don't need etc
• It's harder to test multiple combinations of versions of the different packages in the CI process.
• It's harder to quickly look at an issue or a particularly a PR and know which packages it affects and therefore the potential impact.
• It blurs the division between what should be logically separate packages by making it too easy to change all of them in a single commit
• It makes it hard to have different sets of contributors - eg if we drop official support for ORM but leave it around for people that still use it, it would be good if some of them had access to maintain it.

I don't see there's a real problem with multiple repos - I think it's good that the change history, issues and PR are separate on github, and for working locally composer install --prefer-source should do everything you need.

[neo22s]

Agree @acoulton done here #669 and here #670

[enov]

Thanks @rjd22 @acoulton, yeah, I see the benefit of following Composer's branch naming pattern.

[enov]

@acoulton do you think naming the branches with .x suffix is necessary? 4.0.x instead of 4.0?

[enov]

Recently, I have discovered this repo, and it'll be cool to have those scripts updated as well. I added that to the list and marked as optional, as we can work on them later:

• Update kohana-ci scripts for new branch naming structure (optional)

[acoulton]

do you think naming the branches with .x suffix is necessary? 4.0.x instead of 4.0?

Not sure if it's strictly necessary - composer docs seem to suggest 4.0 would also be ok. But IMO 4.0.x is clearer and makes the difference between the branches and the tags more obvious.

[enov]

v3.3.5 is released.

On the list above, I have added the suffix .x to the branch name. I have also added:

• Update Travis scripts to make the tests pass

[neo22s]

Hello,

Cool! thanks https://github.com/kohana/kohana/releases/tag/v3.3.5

Also whats the channel where we notify customers of new releases? twitter? email ? forum?

How can we see what was changed or new? in a easier way I mean ;)

Thanks a lot @enov

[enov]

Thanks @neo22s!

How can we see what was changed or new? in a easier way I mean ;)

I added a section for the description of changes:
https://github.com/kohana/kohana/releases/tag/v3.3.5

whats the channel where we notify customers of new releases? twitter? email ? forum?

We need to consult @shadowhand for the details, but I say it's not worth it for now. Let's keep the celebrations for v4.0.0.

[neo22s]

@enov thats what I meant xD

Another issue when I go to https://github.com/kohana/kohana/releases/tag/v3.3.5 the ZIP package is missing? I guess you need to do it manually?

Yeah notifying people I think is critical.... I found out about https://github.com/kohana/kohana/releases/tag/v3.3.4 just by luck nothing else :(

thanks again! I am so looking forward to see if things change... I know its hard and there's a lot of stoppers. But we can ;)

[enov]

Another issue when I go to https://github.com/kohana/kohana/releases/tag/v3.3.5 the ZIP package is missing? I guess you need to do it manually?

Done

[neo22s]

Thanks @enov! I will be updating this weekend got a major release today I do not want to risk it xD

I did post it on Twitter:
https://twitter.com/deambulando/status/708213281425657856

http://discourse.kohanaframework.org/t/kohana-3-3-5-released/1020

[enov]

I have removed my previous comment, as it was mostly negative. I will not let things down specially at this time. I might go at slower pace. Thanks.

[svenbw]

Thanks for the release!
I'm using Kohana in a lot of projects and was looking for an alternative to since the project seemed quite dead. Every alternative had some advantages and disadvantages, the biggest problem with switching is finding an alternative for custom written modules... So this release is really good news.
I think it's still a great framework and a new website with a more modern look could promote the framework and hopefully boost the usage (again).

Modules are quite important and one of the keys to get a website quick up and running. Releasing some modules for modern/recent webservices might also help.

[neo22s]

@svenbw welcome! agree on you in everything ;)

@enov I did manage to read your message, didnt want to engage since I do not want to waste anyone's time either in conversations ;) I want to apologize to any member that have felt wrong due to my comment thanking @enov to put all together and do a new release. as said I thanked all the community but who did put it together was you.

I hope you do not step down.... not many people willing to do things here.

Going to the point regarding 3.4.0 and I will not come more, we need to do something and needs to happen ASAP. We need php7 compatibility!

How can I help?

[enov]

I was hyper-stressed my friend, and I am sorry.

[neo22s]

@enov no problem at all dont be sorry hehehe ;)

Ok, last time, how can we move the project forward? what can I do to speed up things?

I have the means....resources, time and willingness... so can I do something?

[enov]

As per our plan, we should now review and take actions on the outstanding PRs, and restructure the milestones. I appreciate the help.

[neo22s]

do we check PR on each module or only in core? I am not sure how works which branch etc...

[svenbw]

If you want to handle all PR's for the different modules the branches of should follow the branch method of the core.
If another branch is added to the core all modules must follow.

It's however a good start. Let's get things moving!

[acoulton]

@enov I'm sorry to be so slow for reply, I'm also flat out at work at the moment. Thanks for pushing on with this. I will try to put some time in when I can but it's likely to be a couple of weeks at least.

@neo22s we need to look at all the modules and particularly to focus on:

• closing any that are redundant, out of date or not of high enough quality to merge
• merging any bugfixes that are backwards compatible so that they can be in 3.3 and 4.0
• merging any breaking changes that are close enough to complete to go with the upcoming breaking 4.0 release
• assigning any longer-term breaking changes (including issues that nobody's started working on yet) to a new 5.0 milestone

[acoulton]

Also anyone with a few minutes of time can do the two easy jobs on @enov's list - renaming the 3.4.0 milestone to 4.0 and deleting any redundant (merged / long-dead and now very conflicting) branches in each module.

[enov]

@acoulton thanks for understanding. I noticed you moved the list to the top (was just going to do that, btw). I added the points in your last comments to the list. 👍

[neo22s]

Ok, I have created an issue for 4.0.0 release. Please lets discuss better there then.

#672