what is wrong with you ? why have a 'poll' on wether we should create a tag or not!!!! First, we MUST create a tag, it's 100% normal, it's the best way to keep track of what we are doing.. imagine in 1 year or 2, we'd have made so many changes to SVN, so many new branches, so many backports of bugs to older branches, etc... then when we want to get the rc2 for example, we won't be able to do it ? everyone works with branches and tags, and that's how it is! you are saying that it's pointless, now, how about, in 3 years, someone says he has a huge bug in 0.96, but it's not appearing in 0.96 rc2, and it was something specific to his pc, noone else on earth could have that bug... but in 0.96 he also had a bugfix for something else, so he wants us to break the bugfix which creates his bug, and to port again the bugfix that he wants back into the rc2 version... best way is to get rc2, and patch it... "now, let me think.. humm. was 0.96rc2 revision 6891 or 6981... damn, if only, back then, 3 years ago, they decided to create a tag... :( " you know what, why don't YOU give me a GOOD reason for NOT creating a tag??? don't forget how SVN works, a whole copy of the repo, a tag or a branch or whatever takes NO space in the repo, so we don't care about the space...
p.s.: every company that releases software creates a tag/label for every build they make, even if it's 100 builds... take a look at : http://svn.wikimedia.org/viewvc/mediawiki/ to see how branches and tags should be used... Next time, we'll make it the right way, we will branch for specific features (example, clgui branch, or amsncore branch) for every big feature we want to implement, instead of branching the next production (0.96) branch.. so the trunk/ is the development.. this means that, we would work on the trunk/ for everything, if we want to modify something huge, we creater a branch, we WON'T need to backport our changes from the trunk/ to that branch, what we'll do, is once that feature is done and complete, etc... we'll tell SVN to merge the two branches together, so that new developed feature gets integrated into the trunk/ automatically. Once we RELEASE, we create a branch for that release, and we'll do commits in that branch ONLY if we need to backport a fix for a custom build or for a new 'bugfix' version (for a critical bug for example).. example, the proxy thing, a huge problem, we had to release 0.96 because of that, if we used what I just described (the svn philosophy), we would have taken the 0.95 branch, applies the proxy fix on it, modifies the SF mirror for downloading tls, and released 0.95.1 with only these two fixes... without the need to force a release of 0.96 anyways.. gtg KKRT KKRT On Thu, 15 Jun 2006 09:26:44 -0400, Jonne Zutt <[EMAIL PROTECTED]> wrote: > > Shouldn't we make a tag of branches/0_96 now (called tags/0_96_1) ? > I think so, because if we commit to 0_96 after the release, we cannot > know what exactly was 0.96.1 in the repository anymore. > And I think that is what Sander meant. > And, iirc, it doesn't consume much repository space, as it is stored > quite clever. > > After reviewing and committing changes between the branch and trunk, > the diff between branch and trunk is almost empty now. > > Why did we create the branches/0_96 in the first place? Was the idea, > stop implementing new features so we can release? (that would be good I > think) Or am I missing something? > > Jonne. > >> > 3) do we create a tag for this release in svn? (A tag and a branch > are >> > the same in svn, technically) So does it have any benefits to create > a >> > tag, when we already have a 0.96 branch, which we can check out by >> > revision number, if bugfixes later are done in this branch. >> >> Make a tag on the main branch? That is pointless because that isnt the > 0.96, >> and we arent going to be integrating changes (accept for bugfixes if > we plan >> to release a 0.96.1). So I think we don't need to tag it. > > > > > > > _______________________________________________ > Amsn-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
