Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 28 June 2016 at 06:55, NAKAMURA Takumi  wrote:
> It has also submodules.
> https://github.com/llvm-project/llvm-project-submodule
>
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

Nice! Can you try a server hook that will add an auto-increment number
from submodules commits?

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 4:57 PM, Hans Wennborg  wrote:
>>> Eh, if we're switching to a completely unrelated versioning scheme, it
>>> doesn't seem completely unreasonable.
>>>
>>> We could also count how many time-based releases we have had and use that...
>>>
>>> :: shrug ::
>>>
>>> I think counting from 4 or counting from 40 are all fine ways to number
>>> releases.
>>
>>
>> This is what I arrived at after my weekend of thinking about version numbers:
>>
>> While there's been many good arguments for doing something different
>> and revising our versioning scheme, I really just want to bump the
>> number with the least amount of work possible.
>>
>> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
>> focus my attention on getting 3.9 into a good state and shipping it.
>>
>> After the branch, if someone wants to promote trunk to 4.0 because of
>> a feature, or because the 3-series is "done", go ahead. If someone
>> wants to spearhead getting us onto a scheme where we increment major
>> for each release, that's fine too, but I'm not going to drive it.
>>
>> Thanks everyone for participating in the discussion. Hopefully this
>> result is not too disappointing.
>
> I continue to think that 3.10 is the least defensible option out there.  We 
> have a time based release process with no mechanism or attempt to align 
> behind “big” releases that could bring is to a 4.x number.  You might as well 
> call the release “10” at this point, since the "3.” will become archaic 
> legacy that we can’t shed.
>
> Trust me, I’ve seen this happen several times in the past in multiple 
> different products (both open source and proprietary), and have had success 
> leading one to a more predictable release number pattern like I’m advocating 
> for.  This is a problem that we are simply walking into by naming it 3.10, 
> there is no reason to do that.
>
> I still don’t understand what “confusion” could be caused by going from 3.9 
> to 4.0.  Could someone please elaborate on what the problem is that needs 
> solving?  If it is that people don’t understand what is major about the 
> release, I would say “who cares”?

I think the main issue (besides users asking what's the big change in
4.0, which I agree is not a big problem) is that the bitcode
compatibility policy is tied to the major version number.

But if you really insist on 4.0 rather than 3.10, I will of course honour that.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Mehdi Amini via lldb-dev]

> On Jun 28, 2016, at 1:55 AM, NAKAMURA Takumi via llvm-dev 
>  wrote:
> 
> It has also submodules. 
> https://github.com/llvm-project/llvm-project-submodule 
> 
> 
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

This is easy to compute when coming from SVN, the difficulty will be to keep 
this when having multiple git repo as a source.

— 
Mehid


> 
> On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev 
> > wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola  > wrote:
> > I think that trying to create a ordering/rev number between independent git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project 
> > .
> 
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
> 
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).
> 
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> > I still don’t understand what “confusion” could be caused by going from
> 3.9 to 4.0.  Could someone please elaborate on what the problem is that
> needs solving?  If it is that people don’t understand what is major about
> the release, I would say “who cares”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

Somebody proposed a time-based-version bitcode compatibility policy.
IMHO the easiest to remember would be "X.Y supports back to (X-1).Y"
but opinions vary (e.g. 3 years, where my idea would mean 5 years) and
nobody has tried to nail one down.

Of course actually removing an auto-upgrade feature means having to do
the archaeology to figure out when each piece was introduced, and then
how to disentangle it cleanly.  I'm not aware that these things are
identified by version, other than by researching the commit history.
With the old scheme, you'd just rip it all out at 4.1 without having
to worry about when each piece was introduced.  With the time-based
scheme there's a higher barrier to removing the old code.
--paulr

> 
> But if you really insist on 4.0 rather than 3.10, I will of course honour
> that.
> 
> Cheers,
> Hans

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Eric Christopher via lldb-dev]

On Tue, Jun 28, 2016 at 12:22 PM Rafael Espíndola 
wrote:

> > I think the main issue (besides users asking what's the big change in
> > 4.0, which I agree is not a big problem) is that the bitcode
> > compatibility policy is tied to the major version number.
>
> It is tied in saying we *can* drop compatibility, not that we will. If
> we still support loading 3.0 bitcode when 4.1 ships we just have to
> document that. It just given us the flexibility to drop it in 4.2 if
> we want.
>
>
I don't think this is as obvious as you might think it is. We can happily
drop the "major version equals bitcode compatibility" implicit promise if
we want, but it's been there for a while and will need some messaging as to
the actual promises here and what we'll do to fulfill and what we mean when
we want to change it (will we actually rev the version? not?). I think
Hans's idea for the release is fine and then will let us argue it as much
as we'd like on llvm-dev until we get a proposal that people are happy with.

-eric
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Rafael Espíndola via lldb-dev]

> I don't think this is as obvious as you might think it is. We can happily
> drop the "major version equals bitcode compatibility" implicit promise if we
> want, but it's been there for a while and will need some messaging as to the
> actual promises here and what we'll do to fulfill and what we mean when we
> want to change it (will we actually rev the version? not?). I think Hans's
> idea for the release is fine and then will let us argue it as much as we'd
> like on llvm-dev until we get a proposal that people are happy with.

The promise just says that 4.0 *will* read 3.X and 4.1 might.

I think I agree with Chris with 3.10 being the worst possible outcome.
If the "may be compatible" is too confusing lets change it to be time
base or just say that llvm for now can read bitcode of llvm 3.0 or
newer but we might change that in the future.

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Tue, Jun 28, 2016 at 12:55 PM Chandler Carruth via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> My 2 cents.
>

And just to be explicit, I 100% support the person doing the heroic work to
*make* our releases having the final say in how they are numbered. =]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Rafael Espíndola via lldb-dev]

> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

It is tied in saying we *can* drop compatibility, not that we will. If
we still support loading 3.0 bitcode when 4.1 ships we just have to
document that. It just given us the flexibility to drop it in 4.2 if
we want.

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Tue, Jun 28, 2016 at 12:45 PM Rafael Espíndola 
wrote:

> > I don't think this is as obvious as you might think it is. We can happily
> > drop the "major version equals bitcode compatibility" implicit promise
> if we
> > want, but it's been there for a while and will need some messaging as to
> the
> > actual promises here and what we'll do to fulfill and what we mean when
> we
> > want to change it (will we actually rev the version? not?). I think
> Hans's
> > idea for the release is fine and then will let us argue it as much as
> we'd
> > like on llvm-dev until we get a proposal that people are happy with.
>
> The promise just says that 4.0 *will* read 3.X and 4.1 might.
>

Yes, but while you have read it and interpreted it precisely, I suspect
that many people have misinterpreted it and assume that 4.0 will be the
last release to read 3.X. They may be incorrect, but I think it would still
be worth considering them and working to communicate this effectively.

Essentially, what Eric said: it may be accurate, but it isn't *obvious*, at
least not to everyone.


>
> I think I agree with Chris with 3.10 being the worst possible outcome.
>

I'd be interested to understand why you or Chris thing 3.10 is the worst
possible outcome.

Chris has said it is because he thinks we'll never change the "3", but I
don't understand why 3.10 is worse than 3.9 was in that respect. I happen
to agree that we'll never change the "3", but I don't think this makes 3.10
a particularly bad choice.


I'm seeing pretty much zero support for continuing to have a major/minor
split. As such, I pretty strongly suggest that as a community we move to a
single integer that increments every (time based) release, and a .N that
increments with every patch release off of that branch. GCC and numerous
other projects work this way.

I actually don't care at all what the number is: 4 or 40 seem fine.

If 4 seems too confusing, and 40 seems too extreme, how about 10.
Seriously. It seems exactly as good as any other integer to start counting
rationally, and won't confuse people by looking like a 4.0 release.

My 2 cents.
-Chandler
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hal Finkel via lldb-dev]

- Original Message -

> From: "Chandler Carruth via Openmp-dev" 
> To: "Rafael Espíndola" , "Eric
> Christopher" 
> Cc: "llvm-dev" , "Chris Lattner"
> , "openmp-dev (openmp-...@lists.llvm.org)"
> , "LLDB" ,
> "cfe-dev" , "David Blaikie"
> , "Paul Robinson"
> 
> Sent: Tuesday, June 28, 2016 2:55:21 PM
> Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] [lldb-dev] What
> version comes after 3.9? (Was: [3.9 Release] Release plan and call
> for testers)

> ...

> I actually don't care at all what the number is: 4 or 40 seem fine.

> If 4 seems too confusing, and 40 seems too extreme, how about 10.
> Seriously. It seems exactly as good as any other integer to start
> counting rationally, and won't confuse people by looking like a 4.0
> release.
I think that there are good marketing reasons to not be stuck at 3.x for a long 
time. People want to use actively-developed software that is neither too young 
(i.e. likely immature) nor too old. Thus, while always being on version 3.x is 
bad, being on version 50 or 100 also might send the wrong message. Given two 
releases per year, I think that starting at 40 is a bad idea, as we'll soon end 
up with numbers that look too large (in some subjective sense). Starting at 8 
or 10 seems better. 

Also, many people are used to the odd/even numbering schemes used by many 
projects (i.e. odd is unstable and even is stable), and I've noticed that some 
people have an unconscious bias as a result, so we might stay away from odd 
numbers for that reason. 

-Hal 

> My 2 cents.
> -Chandler
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hal Finkel via lldb-dev]

- Original Message -
> From: "Hans Wennborg via llvm-dev" 
> To: "Richard Smith" 
> Cc: "llvm-dev" , "Chris Lattner" , 
> "openmp-dev
> (openmp-...@lists.llvm.org)" , "LLDB" 
> , "cfe-dev"
> , "David Blaikie" , "Paul 
> Robinson" 
> Sent: Tuesday, June 28, 2016 3:38:06 PM
> Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] [Openmp-dev] What version comes 
> after 3.9? (Was: [3.9 Release] Release
> plan and call for testers)
> 
> On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev
>  wrote:
> >> If 4 seems too confusing, and 40 seems too extreme, how about 10.
> >> Seriously. It seems exactly as good as any other integer to start
> >> counting
> >> rationally, and won't confuse people by looking like a 4.0
> >> release.
> >
> >
> > I think going to 10 or 40 is likely to be confusing, because
> > there'll be two
> > different ways to refer to the same version (people will say 3.10
> > when
> > referring to version 10, or 38 when referring to version 3.8,
> > respectively).
> > This happened to Java in the version 1.6 / version 6 numbering
> > transition.
> >
> > In order to preserve numbering continuity and minimize confusion,
> > if we go
> > from three-component versions (major.minor.patch) to two-component
> > versions
> > (major.patch), I would suggest we go from x.y.z to x+1.0. (This is
> > also
> > consistent with how GCC handled the transition.)
> 
> I haven't followed how this worked out for GCC, but I worry that if
> we
> go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
> get confused when we ship 4.1 as a "dot" release instead of a major
> release like we've used to.
> 
> There's also the question of how to practically go from a 3-tuple to
> a
> 2-tuple. Should we drop it from the version string and dir names in
> Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I
> see
> GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to
> do it?

I think that the directory names should match the version string. Both are 
user-facing. For the macros, I'd rather set the minor version to 0, since 
"patch level" really is the correct descriptive name for the final digit in our 
stable releases.

 -Hal

> 
> Cheers,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Rafael Espíndola via lldb-dev]

>> The promise just says that 4.0 *will* read 3.X and 4.1 might.
>
>
> Yes, but while you have read it and interpreted it precisely, I suspect that
> many people have misinterpreted it and assume that 4.0 will be the last
> release to read 3.X. They may be incorrect, but I think it would still be
> worth considering them and working to communicate this effectively.
>
> Essentially, what Eric said: it may be accurate, but it isn't *obvious*, at
> least not to everyone.

So lets fix that. What is your preference of wording? Specially if we
go to a single integer model?

>> I think I agree with Chris with 3.10 being the worst possible outcome.
>
>
> I'd be interested to understand why you or Chris thing 3.10 is the worst
> possible outcome.
>
> Chris has said it is because he thinks we'll never change the "3", but I
> don't understand why 3.10 is worse than 3.9 was in that respect. I happen to
> agree that we'll never change the "3", but I don't think this makes 3.10 a
> particularly bad choice.

It makes the "3." look more significant than it is and we will keep
having discussions about what is "major" in the future.

> I'm seeing pretty much zero support for continuing to have a major/minor
> split. As such, I pretty strongly suggest that as a community we move to a
> single integer that increments every (time based) release, and a .N that
> increments with every patch release off of that branch. GCC and numerous
> other projects work this way.

I like this. And that is why I don't like the 3.10. It makes the major
number seem more significant than it looks currently (we avoided
changing it after all).

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Openmp-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
 wrote:
> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev
>  wrote:
>>
>> I think I agree with Chris with 3.10 being the worst possible outcome.
>
>
> I'd be interested to understand why you or Chris thing 3.10 is the worst
> possible outcome.
>
> Chris has said it is because he thinks we'll never change the "3”,
>
>
> Yes, that is one reason.
>
> but I don't understand why 3.10 is worse than 3.9 was in that respect.
>
>
> Because it breaks from the established pattern we have, and means that we
> never get to 4.
>
> I happen to agree that we'll never change the "3", but I don't think this
> makes 3.10 a particularly bad choice.
>
>
> If you agree that we’ll never change the 3, then you are staying that you
> believe it is ok for the version number to be meaningless.  In that case, I
> can’t see why you’d object to a policy change.
>
> I believe that the version number is important.  Which is why I care so much
> about it :-)
>
> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion
> to encode into the version number - from a historical perspective, we only
> used that as rationale because it happened to align well for the 1.9 to 2.0
> conversion and then used it as an excuse to shed some legacy in the 3.0
> timeframe.
>
> Given that, and given that we have a time based release, we should either
> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning
> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42).

Since there seems to be some kind of rough consensus forming around
the idea of moving towards a model with x.y version numbers where we
increment x every six months and y for the "dot" releases in between,
let's take it to a code review:

http://reviews.llvm.org/D21821

What angles am I missing? I'm sure this can break the world in
interesting ways. (It looks like Clang's cmake config is already set
up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).

 - Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev 
 wrote:
> I think I agree with Chris with 3.10 being the worst possible outcome.
> 
> I'd be interested to understand why you or Chris thing 3.10 is the worst 
> possible outcome.
> 
> Chris has said it is because he thinks we'll never change the "3”,

Yes, that is one reason.

> but I don't understand why 3.10 is worse than 3.9 was in that respect.

Because it breaks from the established pattern we have, and means that we never 
get to 4.

> I happen to agree that we'll never change the "3", but I don't think this 
> makes 3.10 a particularly bad choice.

If you agree that we’ll never change the 3, then you are staying that you 
believe it is ok for the version number to be meaningless.  In that case, I 
can’t see why you’d object to a policy change.

I believe that the version number is important.  Which is why I care so much 
about it :-)

I think/hope we can agree that “Bitcode compatibility” is an obsolete notion to 
encode into the version number - from a historical perspective, we only used 
that as rationale because it happened to align well for the 1.9 to 2.0 
conversion and then used it as an excuse to shed some legacy in the 3.0 
timeframe.

Given that, and given that we have a time based release, we should either leave 
the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning model 
3.9/4.0/5.0/6.0 or 3.9/40/41/42).

-Chris

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 28 June 2016 at 16:46, Mehdi Amini  wrote:
> Why? Assuming we don’t have branches, there was many mention that the id can 
> be computed from the number of commits in the history.

We have branches (release_nm) and we may want them to be in the same
sequential numbering.

So, I'm assuming this hook gets executed every time a new commit
arrives, but they're sub-modules, would they also notify the parents?

If this works in a trigger mode (every commit), not a timed basis
(every 5 minutes), then it could work well.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 28 June 2016 at 17:33, Tim Northover  wrote:
> I really like this too, and think Takumi has basically solved 90% of
> the problem for us already. We may want to add an "rN" line to avoid
> scaring people with hex commits, but that seems to be all that's
> lacking and not really essential anyway.

Not so much scaring, but to avoid rushed migrations.

Current SVN-aware handling (downstream infra, bisects) deal better
with sequential numbers, and they may take some time to migrate to
fill Git solution.

We should move all upstream infrastructure, but we can't dictate on
the downstream pace (or it would never happen).

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

> On Jun 28, 2016, at 8:40 AM, Hans Wennborg  wrote:
> 
>> I continue to think that 3.10 is the least defensible option out there.  We 
>> have a time based release process with no mechanism or attempt to align 
>> behind “big” releases that could bring is to a 4.x number.  You might as 
>> well call the release “10” at this point, since the "3.” will become archaic 
>> legacy that we can’t shed.
>> 
>> Trust me, I’ve seen this happen several times in the past in multiple 
>> different products (both open source and proprietary), and have had success 
>> leading one to a more predictable release number pattern like I’m advocating 
>> for.  This is a problem that we are simply walking into by naming it 3.10, 
>> there is no reason to do that.
>> 
>> I still don’t understand what “confusion” could be caused by going from 3.9 
>> to 4.0.  Could someone please elaborate on what the problem is that needs 
>> solving?  If it is that people don’t understand what is major about the 
>> release, I would say “who cares”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

If that is the confusion, then I suggest that we just document (in the release 
notes) what the supported compatibility range is for any release.  That makes 
it completely unambiguous, and means that we don’t have to make an arbitrary 
policy up front (exactly N years of support!), we can drive it based on the 
cost/benefit involved with making a specific change.

Besides, people “expecting” 4.0 to break compatibility will likely ask about 
it, and be pleasantly surprised :-).  I don’t think that the association of 
major number to bitcode compatibility is actually well known outside the core 
group of folks that hang out on llvm-dev anyway.

I think that there is a reasonable argument to be made for switching to a 
semantic versioning model.  Instead of 3.9, 4.0, 4.1 we would switch to 4.0, 
5.0, 6.0 and then “4.1” would be a patch release.  It appears that jumping to 
40 just freaks too many people out.

-Chris

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Diego Novillo via lldb-dev]

On Tue, Jun 28, 2016 at 4:38 PM Hans Wennborg via llvm-dev <
llvm-...@lists.llvm.org> wrote:

I haven't followed how this worked out for GCC, but I worry that if we
> go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
> get confused when we ship 4.1 as a "dot" release instead of a major
> release like we've used to.
>

GCC does one major release a year.  That release gets a new major number.
Subsequent releases during that year get a minor number (
https://gcc.gnu.org/develop.html#timeline)

Diego.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev