Version control done the WTF way



  • @PJH said:

    They get named on release.
     

    So this is a human-generated code (or, more accurately, one decided by a human) rather than an automated increment?

    That makes more sense than picking a milestone and releasing whatever version number that happens to be.


  • Discourse touched me in a no-no place

    @Cassidy said:

    @PJH said:

    They get named on release.
     

    So this is a human-generated code (or, more accurately, one decided by a human) rather than an automated increment?

    Indeed.@Cassidy said:
    That makes more sense than picking a milestone and releasing whatever version number that happens to be.
    Features/bug-fixes are intended/scheduled to be in a release version. Then back/forward ported as necessary. To every branch that's still supported. The problem is there are so many branches that are still supported rather than being deprecated/retired, resulting in (IMHO) unnecessary work.



    While patch files do relieve some of the monotony of this exercise, some of the branches have deviated so far from trunk that they don't work, and the changes have to be manually merged. I've already been bitten by this when, in a manual merge, I fucked up and checked in another bug by accidentally deleting a rather important (aren't they all?) line.



  • @PJH said:

    Features/bug-fixes are intended/scheduled to be in a release version. Then back/forward ported as necessary. To every branch that's still supported. The problem is there are so many branches that are still supported rather than being deprecated/retired, resulting in (IMHO) unnecessary work.
    What kind of WTFness causes you to support 6.18.5 and 6.18.4 and not just tell the people on 6.18.4 "We fixed that in 6.18.5, please upgrade"?


  • Discourse touched me in a no-no place

    @Jaime said:

    @PJH said:
    Features/bug-fixes are intended/scheduled to be in a release version. Then back/forward ported as necessary. To every branch that's still supported. The problem is there are so many branches that are still supported rather than being deprecated/retired, resulting in (IMHO) unnecessary work.
    What kind of WTFness causes you to support 6.18.5 and 6.18.4 and not just tell the people on 6.18.4 "We fixed that in 6.18.5, please upgrade"?
    What you describe in the former is one thing that doesn't happen, what you suggest in the latter is what does. It's (thankfully) not that bad.


Log in to reply