search

CESR-lab / ucla-roms

GNU General Public License v3.0
5 stars 11 forks source link

defining branches #11

Open matt-long opened 8 months ago

matt-long commented 8 months ago

I think we should use branches minimally, preferring forks for most development.

I propose that we use the following branches:

  1. development: active development occurs here; PRs from forks are mostly merged here, except for bug fixes.
  2. stable: once new mods have been deemed acceptable, we submit PRs from development here.
  3. Branches for C-Star or other downstream project releases. The rationale is that when we issue a C-Star release, we'll need a ROMS tag and should create a corresponding branch (e.g., c-star-vX.Y.Z); this enables us to keep features constant, but implement bug fixes. We'd obviously implement the bug fix in development and merge onto stable as well.

Thoughts?

TomNicholas commented 8 months ago

I think that sounds good.

Does that also mean that whilst the development and stable branches would be the responsibility of the UCLA group, the C-Star branches would effectively be something that only the [C]Worthy crew need to manage directly?

matt-long commented 7 months ago

I think the development and stable branches would be considered the core of the ROMS development enterprise—so, yes, owned primarily by UCLA.

nmolem commented 7 months ago

We'll work to get a 'first' stable release that includes the current state of developments, including the gfortran compliant issues and davydd's marbl functionality. After that, further development will be on separate branches, and only hot-fixes will be added to the main branch. Getting to a stable main that includes marbl may take about month if I'm taking a educated guess.