Modify

Opened 10 years ago

Closed 9 years ago

Last modified 4 years ago

#2658 closed enhancement (fixed)

Subversion repository of OpenWrt project : guidelines suggestions

Reported by: nicolas.pichon@… Owned by: developers
Priority: low Milestone: Barrier Breaker 14.07
Component: other Version:
Keywords: svn tags branches guidelines release version Cc:

Description

Having spent a lot of time last week reading changesets to track an issue, searching in different tags and in trunk, I have a few suggestions on how Subversion should be use to facilitate OpenWrt's releasing and changes tracking.

According to SVN logs, it seems to me that the tags/ hierarchy is used a way like most SVN users do in the branches/ hierarchy. Of course, there is no technical distinction between Tags and Branches in SVN, but their difference is a matter of human interpretation.

In a ideal world, branches are created by copying trunk to prepare a future release. Then, the branch has its own life, has commits, bugfixes, till it is considered "stable". Then we make a Tag with the release number (ex : 1.0), which is a freeze of the branch state, and will never have furthers commits. If bugfixing or modification have to be made, they take place in the branch and another tag is made by copying current branch state (ex : to 1.0.1).

What we have now is this :

  • a tags/kamikaze_7.07 which is initially a copy of trunk/ [7832] dated as of 20070701, with 126 commits running till 20070906
  • binaries in http://downloads.openwrt.org/kamikaze/7.07/ , dated as of 20070726, which I suppose are build from revision [8181], as far as I can tell from SVN log
  • a tags/kamikaze_7.09 hich is initially a copy of revision [8679] of tags/kamikaze_7.07; with 31 commits running till 20071007
  • binaries in http://downloads.openwrt.org/kamikaze/7.09/ , dated as of 20070930, which I suppose are build from revision [9075], based on commits dates, but no commit log in SVN can prove it

What I would see would be :

  • a branches/kamikaze_7.07 which is initially a copy of trunk/ [7832] dated as of 20070701
  • all the commits from [7832] to [8181] in branches/kamikaze_7.07
  • a tags/kamikaze_7.07 copied from revision [8181] in branches/kamikaze_7.07
  • binaries in http://downloads.openwrt.org/kamikaze/7.07/ compiled from tags/kamikaze_7.07
  • all the commits from [8181] to [9075] in branches/kamikaze_7.07
  • a tags/kamikaze_7.07.1 copied from revision [9075] in branches/kamikaze_7.07
  • binaries in http://downloads.openwrt.org/kamikaze/7.07.1/ compiled from tags/kamikaze_7.07.1
  • continuing doing bugfixes (and even merging patchs and backports from trunk/) to branches/kamikaze_7.07, and making a release in tags/ when needed
  • and when we think of preparing a new release based on current trunk/, make a branch in branches/kamikaze_7.10 by copying content of trunk
  • commiting bugfixes and backports in branches/kamikaze_7.10
  • when branches/kamikaze_7.10 is considered stable, copying it to tags/kamikaze_7.10
  • generate binaries from tags/kamikaze_7.10 and put them on http://downloads.openwrt.org/kamikaze/7.10/
  • continuing life of branches, creating new ones from trunk/, making releases when needed

Of course, this can sound evident to many of SVN users contributing to OpenWrt, and I don't think to have the smallest authority in the project to tell how things should be done, but I wanted to share my own point of view.

Regards

Attachments (0)

Change History (4)

comment:1 Changed 10 years ago by nicolas.pichon@…

Me again :)

Another thing I wanted to add : there are no tags for the /packages/ hierarchy. So because of this and the fact that there is no fixed revision number in the SOURCE_FEEDS_REV parameters of tags/kamikaze_7.09/Config.in, there is no way to tell which revision was used for the binary packages in http://downloads.openwrt.org/kamikaze/packages/.

comment:2 Changed 9 years ago by nicolas.pichon@…

Seems this bug can be closed now, as I can see commits and releases are made in the right 'branches' and 'tags' hierarchies.

comment:3 Changed 9 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.