basho / riak_pb

Riak Protocol Buffers Messages
Apache License 2.0
70 stars 114 forks source link

OTP20 compatability - suppress export_all warnings in tests. #227

Closed martincox closed 6 years ago

martincox commented 6 years ago

Add -compile(nowarn_export_all) to suppress compiler errors when using -compile(export_all) in test modules.

bryanhuntesl commented 6 years ago

@martincox (branches confusing as ever heh) - shouldn't we be merging the fix to develop-2.2/5 (as that/they is/are really the develop branch), and periodically merging develop-2.2/5 onto develop?

russelldb commented 6 years ago

Let's talk about this. IMO some repos can move forward on develop some we should move forward on develop-2.2. If the changes are for the next release clearly they are for develop-2.2. If they're for "the future" then develop might be the right place for them. The issue is around complex repos like riak_core or riak_kv, where major work has gone on, that is unreleased, untested, and possibly unsupportable for the reduced community going forward.

Previous discussions led to the agreement that we would be working on develop-2.2 for the next release, and then onwards for 3.0…we can decide. IMO we should stick to the 2.2 series and cherry-pick from develops as needed, ultimately renaming develop as basho-develop or something similar. We could make a develop-3.0 Off of develop-2.2 now and remember to rebase/merge until 2.2.5 is tagged.

In short, we need to talk and find agreement again on the process going forward.

martincox commented 6 years ago

I think I did this in response to someone being unable to compile with OTP20, and the fix being trivial. The fact that it's target branch is develop is probably an oversight on my part - but we can change that easily, so no big deal. In fact, I think I did this on the premise that it wouldn't be a part of the next release, but probably included in 3.0 - but didn't have a target branch - so it may be worthwhile creating a develop-3 at this point then, as I plan on doing some of the OTP20 work pretty soon.

I agree that we need a discussion re moving forward. Something that I wonder about is the need to remain backwards-compatible while moving to latest OTP - that's something that we need to reach a consensus on - dunno what everyone's view is on that. Doesn't matter so much for this particular repo, but as we get into the meatier codebases, as @russelldb said, there's more complexity, and handling deprecations over 4 major releases, with backwards/forward-compatibility, becomes a bit of an issue.

martincox commented 6 years ago

Closing as it's done in develop-3.0 bf5449e1f660c83041c73387b4a090e8b92da6c1