https://pantsbuild.org/ logo
Powered by
#announce
  • b

    bored-art-40741

    05/16/2016, 6:44 PM
    Dated? It's the other way around: that constraint is what we have to deal with when we expect to grow as a project and have other users, many of whom will be basically invisible to us
  • w

    witty-crayon-22786

    05/16/2016, 6:44 PM
    in that communication/github-issues seem like a reasonble thing to ask
  • w

    witty-crayon-22786

    05/16/2016, 6:44 PM
    as you've said, this is a question of resources
  • b

    bored-art-40741

    05/16/2016, 6:44 PM
    I think that would be nice, but that it does not reflect reality
  • w

    witty-crayon-22786

    05/16/2016, 6:44 PM
    if no one is using a thing, spending time pretending they might be is a big drain
  • b

    bored-art-40741

    05/16/2016, 6:45 PM
    It's not a drain if we release stable branches infrequently
  • m

    mammoth-pharmacist-54215

    05/16/2016, 6:45 PM
    I think its reasonable to set a cut-off for example we will maintain an patch stable release for N months… 6?
  • a

    ancient-stone-50795

    05/16/2016, 6:46 PM
    One stable branch per month going to mean 12 stable branches a year?
  • m

    mammoth-pharmacist-54215

    05/16/2016, 6:46 PM
    as long as we are clear about that to our users I think its reasonable.
  • b

    bored-art-40741

    05/16/2016, 6:47 PM
    @mammoth-pharmacist-54215: I think that's a good idea. We should at least have a notion of how long a stable branch is supported in concrete time, regardless of versioning
  • a

    ancient-stone-50795

    05/16/2016, 6:47 PM
    This isn't really about keeping a stable branch if this is the case. I doubt we upgraded pants 12 times last year
  • b

    bored-art-40741

    05/16/2016, 6:47 PM
    Which then forces the versioning to slow down
  • b

    bored-art-40741

    05/16/2016, 6:47 PM
    =Eric
  • b

    bored-art-40741

    05/16/2016, 6:48 PM
    Though what @mammoth-pharmacist-54215 said earlier was also interesting: we could have the 1.(N+1).x branch have pre-releases and RCs, where the RCs just become a patch bump
  • b

    bored-art-40741

    05/16/2016, 6:48 PM
    So you can track master with some degree of vetting without having to bump the minor version
  • a

    ancient-stone-50795

    05/16/2016, 6:48 PM
    I guess a fundamental difference between our orgs is that we don't really have a BUILD team to maintain pants. If I volunteer to do a pre-release test its me doing nights and weekends. I can't commit to much.
  • b

    bored-art-40741

    05/16/2016, 6:48 PM
    Which is more in line with semver anyway
  • b

    bored-art-40741

    05/16/2016, 6:49 PM
    So let me drop an example of what I mean here
  • b

    bored-art-40741

    05/16/2016, 6:50 PM
    Say we're on 
    1.0.1
    stable and also working on 
    1.1.x
  • b

    bored-art-40741

    05/16/2016, 6:52 PM
    Week 1: 
    1.1.5-pre0
    . Week 2: 
    1.1.5-pre1
    Week 3: 
    1.1.5-pre2
    Week 4: 
    1.1.5-rc0
    , then maybe we find an issue and patch in 
    1.1.5.rc1
    , then we cut the release as 
    1.1.5
  • b

    bored-art-40741

    05/16/2016, 6:52 PM
    And then the next month we'll end up cutting 
    1.1.6
    if there aren't backwards incompatible changes
  • b

    bored-art-40741

    05/16/2016, 6:53 PM
    So Foursquare would consume 
    1.1.x
    (non-pre), Square would consume 
    1.0.x
    , and Twitter would consume 
    1.1.x
    (including pre releases)
  • b

    bored-art-40741

    05/16/2016, 6:53 PM
    We would only increase the minor version would we had to, which would relax the difficulty of backporting patches because we have multiple stable branches out
  • w

    witty-crayon-22786

    05/16/2016, 6:54 PM
    @bored-art-40741: as documented in https://rbcommons.com/s/twitter/r/3890/ , `pre`s go from master, and 
    rcs
    from a branch. as it stands there (based on my understanding of the previous discussion), it would be impossible to have a 
    1.1.5-pre
  • m

    mammoth-pharmacist-54215

    05/16/2016, 6:55 PM
    @bored-art-40741: ideally I’d want people vetting at least the newest minor/major release and where possible backported fixes.
  • w

    witty-crayon-22786

    05/16/2016, 6:55 PM
    @bored-art-40741: because that would imply merging almost everything from master into the latest stable branch... which would mean it wasn't very stable
  • b

    bored-art-40741

    05/16/2016, 6:55 PM
    That is true, but it would also be vetted
  • b

    bored-art-40741

    05/16/2016, 6:56 PM
    It only becomes a non-pre release after a full rc cycle
  • b

    bored-art-40741

    05/16/2016, 6:56 PM
    Which is already how we plan to move changes from master to a stable branch
  • m

    mammoth-pharmacist-54215

    05/16/2016, 6:56 PM
    @witty-crayon-22786: you could have the master branch handle current dev (trunk), and releases would be tagged with either 1.1.5-preN or 1.1.5-rcN depending on if we were ready to release or not… once we get to th RC stage it would be merged into 1.1.x and tagged appropriately
1...456...206Latest