[Checkins] [zopefoundation/keas.build] 1f29c3: currently keas.build will not use unchanged trunk ...

GitHub noreply at github.com
Wed Mar 6 14:54:53 UTC 2013


  Branch: refs/heads/new-product-generation-in-branch-release
  Home:   https://github.com/zopefoundation/keas.build
  Commit: 1f29c3670831ac81c27f0650b70c27b21c01d9d8
      https://github.com/zopefoundation/keas.build/commit/1f29c3670831ac81c27f0650b70c27b21c01d9d8
  Author: Roger Ineichen <roger at projekt01.ch>
  Date:   2012-12-13 (Thu, 13 Dec 2012)

  Log Message:
  -----------
  currently keas.build will not use unchanged trunk packages if the related branch package was released.
This ends in pick a branch package release version for the next trunk release. NOTE: this is fine and correct as long as the branch contains bugfixes. But our branch contains a new complete product rewrite (new product generation). Such a new product rewrite contains the same packages but complete new software which could not get mixed within trunk package.

NOTE: I guess the above is not really correct. Imagine what happens if you change a package in the trunk where you have a bugfix
release for from a branch and didn't backport the bugfix from the branch to the trunk. Such bugfixes get lost because the next
release will get released from the trunk. (the trunk changes forces to do so). But that's another problem and has nothing to do 
with what I'm try to solve. (that's just a bugfix must get back ported ASAP problem)

What I try to do now is to find a way that a trunk/branch (option -b branch in keas.build) package release get not mixed within other branches. If this is not possible the fallback would be to make sure that all branches, where release get made from, get involved in find a new version. This would at least make sure that we pick a newer version then ever was released from any trunk or branch for each package.

In short words, we need completly independent trunk and branche releases because our branch contains a new software generation which is not compatible with the trunk. Currently keas.build only uses branch release as future package fixes for the trunk.


  Commit: 2b480e7f3f8cb434bdf2f62981262e6c0ee00900
      https://github.com/zopefoundation/keas.build/commit/2b480e7f3f8cb434bdf2f62981262e6c0ee00900
  Author: Roger Ineichen <roger at projekt01.ch>
  Date:   2012-12-13 (Thu, 13 Dec 2012)

  Changed paths:
    M CHANGES.txt
    M src/keas/build/base.py
    M src/keas/build/package.py

  Log Message:
  -----------
  - feature: added -i --independent-branches option. This option will force
  to check if the last release was made from the same branch we are
  releasing from. This is required if you develop a new software generation
  in a branch which is independent from the trunk. Previous version of
  keas.build where only able to handle branch releases as bug fix releases
  and didn't make sure that we don't mix trunk and branch releases. Now with
  the -i option we force that all released packages will be made or reused
  based on the current trunk or branch (-b trunk)

- added more logging infos for find or skip next version which makes is simpler
  to see what's going on


  Commit: 4b0474666f342b5d9de32ced06e7a13431591edb
      https://github.com/zopefoundation/keas.build/commit/4b0474666f342b5d9de32ced06e7a13431591edb
  Author: Roger Ineichen <roger at projekt01.ch>
  Date:   2012-12-13 (Thu, 13 Dec 2012)

  Changed paths:
    M src/keas/build/package.py

  Log Message:
  -----------
  - getBranchURL returns non consistent urls, sometimes ending with / sometimes not. At least fix this in our new independent version check
- group logging output


  Commit: 3aa36074a478b480af79a9f11c655c3108556dde
      https://github.com/zopefoundation/keas.build/commit/3aa36074a478b480af79a9f11c655c3108556dde
  Author: Roger Ineichen <roger at projekt01.ch>
  Date:   2012-12-26 (Wed, 26 Dec 2012)

  Changed paths:
    M src/keas/build/index.txt

  Log Message:
  -----------
  update doc


Compare: https://github.com/zopefoundation/keas.build/compare/1f29c3670831^...3aa36074a478


More information about the checkins mailing list