Branch layout

[Rafał Krzewski]

Hello team,

I've just merged PR 49 [1] into scala_2.10 branch, because that's what the author pointed it at. I have a feeling that it isn't the right place, or maybe it isn't the only place where it should go. I looked in the Developers [2] section of Scalate documentation and I don't see anything about the branches plan. We have quite a few:

master

scala_2.7

scala-2.8.x

scala_2.9

scala_2.10

scala_next

scalate-1.1.x

scalate-1.2.x

scalate-1.3.x

scalate-1.3.2.x

nowebgen

mads379_2.8.1

sandbox

It looks like quite a few of the branches are never going to see any further development and could be archived (eg using a tag <branchname>.final) others could be dropped.

The branches that should remain should be, according to my knowledge:

master

scala_2.9

scala_2.10

scala_next

All new work (including community PRs) should go to master and be merged from there to the scala_* branches.

scala_next should be using 2.11-SNAPSHOT now, but it should be an easy ride this time because 2.11 will be backwards compatible with 2.10 on source level.

Please let me know if my understanding is correct, and if now, what the actual plan is :)

Cheers,

Rafał

[1] https://github.com/scalate/scalate/pull/49

[2] http://scalate.fusesource.org/developers.html 

[Ross A. Baker]

Thanks, Rafał.

How would master be different from the scala_* branches?  It seems to me that's one more than necessary.  One of the Scala version branches could be called master, but I don't think we need n+1 branches for n supported versions of Scala.

--
You received this message because you are subscribed to the Google Groups "Scalate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalate+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA

[Rafał Krzewski]

Master would just correspond to scala_2.10 at this point. If all new code goes into master, scala_2.10 will reach the same commit as master when fully merged.

It's just a matter of convention really, many projects use that moniker for the mainline of development.

Since scala_2.10 appears to be the HEAD of scalate github repository (default branch that is displayed when browsing / default local branch on git clone) we could decide to just use that instead.

In which case we should clean it up (there are 6 commits in master not merged to scala_2.10) and get rid of it.

Cheers,
Rafał

[Ross A. Baker]

I've noticed on other projects when there's no "master," people get confused about where to target a pull request.  Maybe for that reason, it makes sense for Scala 2.10 == default == "master", and a 'scala_2.9" branch for continued backporting of master.

I'll defer to anyone with a strong opinion on this, as long as the number of branches we have to manage shrinks. :)

[Rafał Krzewski]

All right then, I'll prepare a PR for bringing the unmerged changed in master into scala_2.10 over the weeked.

I'll also try to prepare another PR for backporting changes made to scala_2.10/master since last release into scala_2.9 but that could be more work.

other than that I'd like to archive the following branches as tags:

scala_2.7

scala-2.8.x

scalate-1.1.x

scalate-1.2.x

scalate-1.3.x

scalate-1.3.2.x

and drop the branches:

master

scala_next

nowebgen

mads379_2.8.1

sandbox

I'll take a look at the unmerged commits in the last three and report back.

I'd really appreciate if James and Hiram could comment on this plan!

Cheers,
Rafał

[Rafał Krzewski]

https://github.com/scalate/scalate/pull/53 is up for review. 

All tests pass, but I had to fix a failing test for Coffescript filter / pipeline. Apparently, it was failing since https://github.com/scalate/scalate/pull/50 was merged, but we don't have a CI running :(

Cheers,
Rafał

[Matthew Farwell]

Just for info, there are a number of companies that do free jenkins etc for open source companies, include Cloudbees http://www.cloudbees.com/foss/index.cb.

I'm not affiliated with cloudbees in any way btw.

Matthew Farwell.

2013/7/13 Rafał Krzewski <rafal.k...@gmail.com>

[Rafał Krzewski]

Yeah, I know that one, it has been considered, along with https://travis-ci.org/

If I recall correctly, finally someone volunteered to set up a CI build on their company Jenkins, but somehow it did not materialize.

Cheers,

Rafał