Release strategy/roadmap

[loonies]

This should be more of workflow discussion..

There should be some kind of release strategy for stable and development version of Jelly, so we know when to expect API changes, upgrade problems etc. ATM there is only develop branch and there is no stable one, ATM we only distinguish between kompatibility with Kohana.

I would like to see API locked for 1.0 ASAP and then some good discussion about 2.0 release. Jelly feels bloated all over and I would like to clean up API and internals. I know Jon started with rewriting in the jonathangeiger/kohana-jelly/experiments branch, but then leaved the project.

[creatoro]

There are two issues remaining before the creating of the master branch. Having done this would mean an API freeze and we can call that 1.0.

In the near future I would have cleaning up Jelly and having tests for everything as a top priority. Jelly is feature rich already, creating new features is a nice thing, but it's better to build on a solid base.

As I see it, the main development should focus on the current Kohana version, which would mean only bug fixes for the preceeding Kohana version compatible branch. However I don't think there's a need for a time-based "release cycle". We should keep going and add changes to Jelly as we have time.

Version number jumps:

• API breaking changes: from 1.0 to 1.1
• non-API breaking changes: from 1.0 to 1.0.1.

Also, it would be a good thing to outline some rules we follow during the development of Jelly, for example:

• validation will match the way Kohana's ORM validation works
• comment everything, even the smallest piece of code

[marcalj]

I agree completelly. Also can you change the name of the repo without loosing "everything"? "kohana-jelly-for-Kohana-3.1" is now obsolete :)

[creatoro]

I've been thinking about renaming the repo to simply "jelly", I'm not sure what problems might be caused by this.

[marcalj]

Nothing in the FAQ, probably you should contact GitHub: https://github.com/contact

[creatoro]

The main caveats:

• We will not set up any redirects from the old location
• You will need to update your local repositories to point to the new location

It might not worth it...

[leth]

I changed username a while back; I re-registered the old one to act as a placeholder.

You could create a new repo with the old name containing migration instructions in a README.md :)

[creatoro]

@leth: not a bad idea! :)

p.s.: can you comment on the other issues?

[leth]

Also: when you change repo name, it might also be worth asking github if they could bless the new one as the 'root' repo.
i.e. It'd no longer say 'forked from jonathangeiger/kohana-jelly'

I did it with one of mine before, it's something they have to do manually. Hopefully the description on Jon's repo should be enough permission for them.

[creatoro]

I'm no sure if that's necessary. There's a lot of people still watching Jon's repo and it would be a good indication what is this repo.

[leth]

Fair enough. Perhaps just send him a casual message to ask if he could update the link on the repo dscription when he gets the time :)

[creatoro]

Will do.

[creatoro]

Another guideline for development could be if a new, major Kohana version (for example 3.2) is available the steps to follow are:

1. Add all the valuable changes from the new Kohana version to Jelly which don't require compatiblity with the new version
2. Create the develop branch for the new Kohana version
3. Fix incompatibility
4. Add changes that couldn't be added in step 1 to the develop branch
5. Create master branch for the new Kohana version

[leth]

I'm not too bothered about this, but it might be a good time to move the Jelly auth drivers to a different repo.

[loonies]

@creatoro
OK, I see. I completly agree about unit testing. So, you are suggesting we move one step at the time, but besides that there shoud be some kind of general discussion about arhitecture, some general thoughts what we should redesign, where we see problems etc...

Also, may be worth to schedule meeting (something like Arch Linux - Bug Squashing Day)

@leth
+1 for removing auth from Jelly

+1 change the repo name, it's confusing :)

[creatoro]

@loonies: I don't mind having new features, but it would be really nice to make Jelly smaller, faster and well tested... If we don't focus on that at least we have to make sure that new features are very well implemented, commented and unit tested.

I agree about having discussions to how to move forward.

Why do you guys want to remove the Auth driver? It's included in ORM as well and it makes converting between the two modules easier.