IRC channel logs
2024-05-29.log
back to list of logs
<fossy>stikonas: my guess is a holdover from before we had exec in kaem <fossy>well it is that too, but that was just me copying what we used previously without considering the use of exec :D <fossy>stikonas, Googulator: I've created a 1.0 branch. I really cannot think of anything that we should wait for at this point before making a 1.0 branch. any changes we'd want in 1.0 are small enough to be merged into 1.0 I reckon <fossy>On a similar note, i reckon cherry-pick or rebase changes into 1.0 rather than merge? <fossy>happy to hear other opinions though <matrix_bridge><Andrius Štikonas> So it might be cherry pick and then amend <matrix_bridge><Andrius Štikonas> There might be mes 0.26.1 soon or are we skipping it? <fossy>should be a pretty straightforward update? happy for it to go in <janneke>yes, i'd like to release mes 0.26.1 real soon now (preferrably within 1-1.5 weeks) <janneke>the only open issue that i know of is the setjmp/longjmp question <matrix_bridge><Andrius Štikonas> But in the worst case we leave it as is for now <janneke>right; in any case, more mes releases will follow soon where it could land <Googulator>fossy: IMO explicit 1.0 bug fixes should be filed as PRs against the 1.0 branch, and then can be merged into 1.0 regularly (followed by a merge from 1.0 to master). Backports from master to 1.0 need to be done via cherry-pick. <fossy>hmm, maybe for bugs that only exist in 1.0, but it seems strange to me to do PR -> 1.0 -> master when the bug exists in master aswell... <Googulator>My rationale for that is a general preference for merges over cherry picks, since merges preserve change tracking information that cherry picks lose <Googulator>although rename tracking isn't a concern in Git as much as it was in Mercurial, because of Git's heuristic rename inference