Merb 1.0 RC1 delayed (by few hours hopefully)

Tonight, the core team members present during MerbCamp got together at my place to prepare and release 1.0 RC1.

The problem is that we spent more time joking, laughing and arguing about the new git system that we didn’t feel right about pushing a release at 4am :(

The git -core and -more repos got merged into a centralized repo. You will notice an active branch and that’s where most of the hacking is going on.

Each core team member has a fork of the project and we all create a new branch everytime we work on a new feature or bug fix. Branch comments get squashed into 1 comment, merged back into the local rebased active branch. The commit get then pulled by Yehuda or pushed to his active branch. Yehuda then make sure all the commits are clean and merge them back in master (edge).

Releases will have their own branches and tags.

People wanting to hack on a specific feature should really fork a core member branch. Usually a core member involved with what you want to work on. Of course that’s optional but whatever you do, if you want to hack on Merb, please use the active branch and not master.

It’s 4:15am, and we are still cleaning up the last few quirks before the release, I know we planned on a releasing today but I guess it’s better to wait few more hours and to get a solid release.

Sorry about that :(

Similar Posts


  1. #1 by wosmvp - October 13th, 2008 at 05:27

    SF :)

  2. #2 by Geoffrey Grosenbach - October 13th, 2008 at 08:37

    For what it’s worth, I think this is a bad idea, especially at the last minute before a stable release.

    We have a ton of tutorials out there linking to the other repositories. Surely one could use git submodules to include the others into a master repository without abandoning the existing repositories?

  3. #3 by Geoffrey Grosenbach - October 13th, 2008 at 09:17

    Ok, so I talked to Yehuda on IRC and got an explanation, which makes a bit more sense. The idea is that it will be easier to maintain backwards compatibility for merb-core and merb-more if they are in a single repo and can be patched together.

    And I assume that the other repos will be updated with a README that directs people to the new one.

  4. #4 by Yehuda Katz - October 13th, 2008 at 09:17

    @Geoffrey we had previously discussed making this change before the RC to make it easier to backport atomic changes that happen in both -core and -more. Previously, it was very difficult to be sure that two checkouts of -core and -more were in sync.

    Despite the whimsical nature of the post, we actually discussed the change all of last week, and were mostly locking down the specifics of the process going forward (is “active” a fork or a branch, etc.).

  1. No trackbacks yet.

Comments are closed.