Child pages
  • Changes in current CVS Dev. procedures and Structure for Open Source
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-org/browse_thread/thread/eebd644be65dcba6#

We need to address and finalize:

1. CVS Line of Development logic and scheme.

Alex and me were working on this for some time and soon we'll have this Scheme ready.

2. One of the crucial things with opening In-Portal to the Public and getting more interested from outside developers is to make CVS READ/CHECKOUT available for anyone willing to participate and contribute to the project.

Community has NO intentions to give a Commit access to anyone until that person is TRUSTED and reached required "Credibility Level" to perform his own commits. Until then we'll be asking users to communicate and work with already Trusted developers and provide fixes, patches to them or directly in a Bug Tracker system.

I'd like to hear everyone's opinion on this.

8 Comments

  1. Today I will only describe release rotations. I will attach scheme
    tomorrow.

    In this example we are starting from 5.0.0 release made from RC
    branch.
    When release is made, then at the same time there are create 2 more
    branched (from RC too):
    * 5.0.dev - development branch for bugfixes of 5.0.0 version (major
    and minor versions are same as main release and "dev" is put instead
    of micro version).
    * 5.1.dev - development branch for features for 5.1.0 version (major
    version is same, minor version is increased by one and "dev" is put
    instead of micro version).

    When bug(-s) is found, then change is made in 5.0.dev branch only. At
    any time we can create bugfix release from 5.0.dev branch named 5.0.1,
    5.0.2 and so on ("dev" part of bugfix branch is replaced with number).
    After bugfix release is made current state of 5.0.dev (what was
    released before) branch is merged back to RC branch (latest released
    version of code) and to 5.1.dev branch (5.1.0 features development
    branch).

    When decided to add new feature, then change is made in 5.1.dev branch
    only. At any time we can create feature(+bugfix) release from 5.1.dev
    branch named 5.1.0RC1, 5.1.0RC2 and so on ("dev" part of bugfix branch
    is replaced with RC+number). After feature(+bugfix) release is made
    current state of 5.1.dev branch is merged back to RC branch (latest
    released version of code).

    At any time RC branch will contain latest released version of code
    (bugfixes + features).

    When we decide to create 5.1.0 release, then we just create branch
    from RC. After that we create 5.2.dev branch (new features of 5.2.0
    release) and use existing 5.1.dev branch (feature branch before) for
    bugfixes after 5.1.0 release. And so on.

  2. Test for reply from email to thread

    Alexander Obuhovich
    R&D Manager
    Intechnic Europe Ltd.
    http://www.intechnic-europe.com
    http://www.in-portal.net
    Phone: +371 7804099
    Fax: +371 7804098

  3. Test, that attachment in email is used in thread

    Alexander Obuhovich
    R&D Manager
    Intechnic Europe Ltd.
    http://www.intechnic-europe.com
    http://www.in-portal.net
    Phone: +371 7804099
    Fax: +371 7804098

  4. Sasha,

    Yes, this looks good and all make sense to me, but how many Lines of
    development we can realistically handle at the same time? Example, 5.0.dev,
    5.1.dev and 5.2.dev? or just first two?

  5. Sasha,

    Nice work with attachment. Do you think we can arrange this in Visio
    format? ;)

  6. Yes, only two branches: last release bugfixes and next release features. In case if you want to apply features from latest releases to previous releases, when this scheme will not work. With currently described scheme we can

  7. Release scheme v2.0

    Alexander Obuhovich
    R&D Manager
    Intechnic Europe Ltd.
    http://www.intechnic-europe.com
    http://www.in-portal.net
    Phone: +371 7804099
    Fax: +371 7804098

  8. Kostia,

    Would you please scan (like Alex did) and attach your version of the
    CVS Development tree so we can see and choose better and detailed one.
    I believe it time to create an official In-Portal CVS Release Schema.
    If I am not mistaken you created one last week. When do you think you
    can post it here?

    Thanks.

    DA.