Ø We can solve the same sort of challenge (the desire to eject old autoupgrade code) by having a sliding window of versions supported (e.g. version 4.5 supports back to version 3.6).
How easy/hard is it to identify the minor release associated with a particular auto-upgrade feature? My impression is that they aren't identified that way in the source, that it would be an archeological dig each time to figure out which bits could be removed. --paulr From: Chris Lattner [mailto:clatt...@apple.com] Sent: Saturday, June 18, 2016 9:16 PM To: Richard Smith Cc: Hal Finkel; llvm-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev; r jordans; cfe-dev; Robinson, Paul Subject: Re: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers) On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <cfe-...@lists.llvm.org<mailto:cfe-...@lists.llvm.org>> wrote: I think that this is the right approach, and we happen to have a natural forcing function here: opaque pointer types. I think we should increment the major version number when opaque pointer types are here, as it will be a major breaking change, and then we'll have a version 4.0. Until then, unless something else breaking comes up, 3.10 sounds fine to me. We're talking about version numbers for the entire LLVM project here, which encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is utterly irrelevant. I'm not convinced that tying version numbers to backwards-incompatible changes to IR is reasonable any more, and it doesn't seem hard to explicitly document the oldest version with which we are compatible (in fact, we need to do that regardless, whether we say it's "the same major version" or "everything since 3.0" or whatever else). Given that our releases are time-based rather than feature-based, I don't see a distinct major / minor version being anything other than arbitrary, so I'd suggest we take 4.0 as our next release, 4.1 as the first patch release on that, 5.0 as the next release after that, and so on. I completely agree with Richard here. “Breaking of IR compatibility” was an interesting metric for older and less mature versions of LLVM. We can solve the same sort of challenge (the desire to eject old autoupgrade code) by having a sliding window of versions supported (e.g. version 4.5 supports back to version 3.6). -Chris
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
