search

creatoro / jelly

A flexible ORM for Kohana 3.1+
http://jelly.jonathan-geiger.com
MIT License
72 stars 13 forks source link

Release strategy/roadmap #78

Open loonies opened 13 years ago

loonies commented 13 years ago

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 commented 13 years ago

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:

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

marcalj commented 13 years ago

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 commented 13 years ago

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

marcalj commented 13 years ago

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

creatoro commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

@leth: not a bad idea! :)

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

leth commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

Will do.

creatoro commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

@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 commented 13 years ago

@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.

loonies commented 13 years ago

@creatoro Don't get me wrong, if you ask me, I would rewrite Jelly from the scratch. I would like to see KISS, well tested arhitecture in Jelly.

We want to remove auth, bc of KISS :) and if ORM does something, it doesn't mean we should follow.

creatoro commented 13 years ago

You're right, we don't have to. These are practical things, which are intended to help others more easily adapt to Jelly.

marcalj commented 13 years ago

Move to another repo but don't remove it! :S (Jelly Auth)

creatoro commented 13 years ago

Well, never thought this would come, but we have a 3.1/master branch and a 3.2/develop branch now :).

marcalj commented 13 years ago

Congrats!

creatoro commented 13 years ago

Thanks guys for contributing, it's great to see Jelly is alive and kicking!