Thread: [Winmerge-development] 2.14 stable branch created!
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
From: Kimmo V. <ki...@wi...> - 2010-09-22 15:55:02
|
Hi all, as we are going to bump the version number of the next 2.12.x stable release to 2.14 I also created new stable branch for 2.14.x releases. The branch name is R2_14 and can be checked out from URL: https://winmerge.svn.sourceforge.net/svnroot/winmerge/branches/R2_14 The branch was created from current 2.12 branch so all "stable" commits are already included. Now the 2.12 branch is finally and really closed, no commits there anymore! For 2.14 branch we are first in "soft freeze" mode meaning: - new features and UI changes can be merged from trunk if agreed so. So if you think some change would be good and is low-risk change you can propose it to be included. Use mailing lists of devel forum for that. Or submit a patch item to patch tracker. Don't bother suggesting big refactorings of code. - main focus should be to merge safe bug fixes from trunk to 2.14 branch. - After few weeks of this "soft" mode we go into normal "bug fixes" only mode and also freeze GUI strings for the release. When this happens depends how fast we merge things and how much there is to merge. So this is a nice opportunity to release really good (based on already stable version) WinMerge version if we are careful what we merge from trunk. And as before with stable branches, commit must be first done to trunk and only after that merged to 2.14 branch. Unless the commit is really 2.14-branch specific (rare commits are). Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2010-09-29 15:38:26
|
Hi, > Looks to me like the doc build scripts (Docs/Users/Manual/build/) are > out of date. At least, they're missing a lot of the changes that I > made for 12.2. That is weird. I created the 2.14 branch from tip of 2.12 branch so everything that was in 2.12 branch is in 2.14 branch now. For some reason your changes weren't in 2.12 branch at all? > Is this a mistake, or are the docs not going to be rebuilt for 12.4 > and it doesn't matter? Sounds like a mistake to me. I don't think there will be any big changes for manual for 2.14. Or at least I'm not going to do any such changes. Regards, Kimmo |
From: Denis B. <den...@gm...> - 2010-09-29 20:09:11
|
Hi Kimmo, Sounds like we at least want to bump the revision numbers in the manual, so I took a look at the log of the Manual directory. At that level at least, 2.14 doesn't seem to have all the 2.12 revisions. It's missing from 6815 through 7033. The resulting differences are easy to find (thanks to WinMerge): * There are only a handful of affected doc sources with a few missing things (like, the xq option that you added in -r6941). * The build files are broken. I think I could easily fix and test the doc problems manually if you like, because just a few files are involved. Let me know if you want me to do that, or if you prefer to fix the merge. Regards, Denis On Wed, Sep 29, 2010 at 11:38 AM, Kimmo Varis <ki...@wi...> wrote: > Hi, > >> Looks to me like the doc build scripts (Docs/Users/Manual/build/) are >> out of date. At least, they're missing a lot of the changes that I >> made for 12.2. > > That is weird. I created the 2.14 branch from tip of 2.12 branch so > everything that was in 2.12 branch is in 2.14 branch now. For some reason > your changes weren't in 2.12 branch at all? > >> Is this a mistake, or are the docs not going to be rebuilt for 12.4 >> and it doesn't matter? > > Sounds like a mistake to me. I don't think there will be any big changes for > manual for 2.14. Or at least I'm not going to do any such changes. > > Regards, > Kimmo > |
From: Kimmo V. <ki...@wi...> - 2010-09-30 16:17:05
|
Hi, > The resulting differences are easy to find (thanks to WinMerge): > > * There are only a handful of affected doc sources with a few missing > things (like, the xq option that you added in -r6941). Ok, good that there aren't bigger changes missing. > * The build files are broken. > > I think I could easily fix and test the doc problems manually if you > like, because just a few files are involved. Let me know if you want > me to do that, or if you prefer to fix the merge. Yes, go ahead and fix the problems. As we haven't been doing any real merges in Subversion it is manual work anyway and you know the docs better than me. Regards, Kimmo |
From: Denis B. <den...@gm...> - 2010-09-28 13:02:05
|
Hi Kimmo, Looks to me like the doc build scripts (Docs/Users/Manual/build/) are out of date. At least, they're missing a lot of the changes that I made for 12.2. For example, in R2_14, build_common.xsl seems to have been branched from -r 5784, which was commited August 10, 2008. The last version of this file in 12.2 was -r 7703, commited November 10 2009. Is this a mistake, or are the docs not going to be rebuilt for 12.4 and it doesn't matter? Thanks, Denis On Wed, Sep 22, 2010 at 11:54 AM, Kimmo Varis <ki...@wi...> wrote: > Hi all, > > as we are going to bump the version number of the next 2.12.x stable > release to 2.14 I also created new stable branch for 2.14.x releases. > > The branch name is R2_14 and can be checked out from URL: > https://winmerge.svn.sourceforge.net/svnroot/winmerge/branches/R2_14 > > The branch was created from current 2.12 branch so all "stable" commits > are already included. > > Now the 2.12 branch is finally and really closed, no commits there anymore! > > For 2.14 branch we are first in "soft freeze" mode meaning: > - new features and UI changes can be merged from trunk if agreed so. So > if you think some change would be good and is low-risk change you can > propose it to be included. Use mailing lists of devel forum for that. Or > submit a patch item to patch tracker. Don't bother suggesting big > refactorings of code. > > - main focus should be to merge safe bug fixes from trunk to 2.14 branch. > > - After few weeks of this "soft" mode we go into normal "bug fixes" only > mode and also freeze GUI strings for the release. When this happens > depends how fast we merge things and how much there is to merge. > > So this is a nice opportunity to release really good (based on already > stable version) WinMerge version if we are careful what we merge from trunk. > > And as before with stable branches, commit must be first done to trunk > and only after that merged to 2.14 branch. Unless the commit is really > 2.14-branch specific (rare commits are). > > Regards, > Kimmo > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Winmerge-dev mailing list > Win...@li... > https://lists.sourceforge.net/lists/listinfo/winmerge-dev > |