I'd like to try convincing you to just drop issues that were in 1.3.0. I assume that 1.4 will become our new stable line. Suppose that I am running on our stable 1.2 release line. When considering an upgrade to 1.4.z, which CHANGES files do I have to read to get a sense of what I have to look out for in changes?
Presuming the 1.3.0 CHANGES files contains everything that changed since 1.2.0, I could just read the 1.3.0 CHANGES and then the CHANGE for the 1.4.z release I am aiming for (since it will have 1.4.0 - 1.4.z in it). If you use a later 1.3.z as the basis, then I have to find what the last 1.3.z that had its RC created before 1.4.0. (a later one will cover changes that are not included in 1.4.0 and might not be in any 1.4.z yet) On Thu, Nov 9, 2017 at 12:05 AM, Stack <[email protected]> wrote: > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell <[email protected]> wrote: > >> You may notice I'm dropping '1.4.0' from fix versions wherever we have >> something that went in to any 1.3.x. This is because I am basing the >> CHANGES.txt changelog for 1.4.0 on the latest from branch-1.3, so anything >> that went in on branch-1.3 will be included in the changelog at the correct >> point in history. Anything in the 1.4.0 section of the changelog for >> branch-1.4 will be for changes in branch-1.4 not in branch-1.3. >> >> > If 1.4.0 goes out before 1.3.2, does that mean, there will be fixes that > are in 1.4.0 (because they were committed post 1.3.1) not mentioned in > 1.4.0 CHANGES.txt? > > Seems fine. Just asking. > > St.Ack > > > >> -- >> Best regards, >> Andrew >> >> Words like orphans lost among the crosstalk, meaning torn from truth's >> decrepit hands >> - A23, Crosstalk >>
