1.0 release status

[twmb]

1.0 is coming soon. This issue tracks what I'd like to accomplish beforehand.

• Possible record loss on unclean kill of consumer when using automatic offset commit #57 should be addressed
• RetryTimeout => rename RetryTimeoutFn, add new RetryTimeout option with a static time.Duration argument
• RetryBackoff => rename RetryBackoffFn (a static RetryBackoff will not be added, because linear static backoff is not a great backoff strategy)
• ProduceRetries => rename RecordRetries
• add func DialTLSConfig(*tls.Config) option, which will trigger dialing by tls (simplifies setting up tls)

Some of these are breaking changes to things that are currently seldom used.

[twmb]

v0.10.0 addresses all but #57.

A few ideas were included in the original comment but have since been nixed due to not really being any better than what exists.

[twmb]

v0.10.2 addresses #57. This release will sit for a short amount of time, if no bug reports come in, v1.0.0 will be released.

[twmb]

Another 1.0 rename that does not need a dedicated tag before 1.0:
AllowedConcurrentFetches => MaxConcurrentFetches

[twmb]

I've written down the entire API, proposed changes for a batch of options, and bounced the proposals back and forth a bit. I think the following set of options should be changed as well before a 1.0 release:

ConnTimeoutOverhead => RequestTimeoutOverhead
  - Why? Request is clearer as to the intent of what this timeout is
Balancers => BalanceStrategies
  - Why? This is closer to the Kafka terminology, and more similar to what
    Sarama uses. I also like that strategies implies these are just algorithms.

CommitCallback => AutoCommitCallback
  - Why? This function is only used for autocommitting. Manual committing
    always requires explicit callbacks already.

OnAssigned => OnPartitionsAssigned
OnRevoked => OnPartitionsRevoked
OnLost => OnPartitionsLost
  - Why? This better implies the meaning of the function.

BatchCompression => ProducerBatchCompression
BatchMaxBytes => ProducerBatchMaxBytes
Linger => ProducerLinger
  - Why? It is conceivable that BatchCompression / BatchMaxBytes could be
    confused with consumer fetch behavior. Adding a Producer prefix makes these
    options unambiguously clearer what they are for.

StopOnDataLoss => StopProducerOnDataLossDetected
OnDataLoss => ProducerOnDataLossDetected
  - These are already niche options, and I want them to be even more explicit
    because they are a bit confusing.

RecordTimeout => RecordDeliveryTimeout
  - This is closer to the Kafka terminology (delivery.timeout.ms), while
    retaining that this is specific per record (internally, per batch).

The following were close, but I don't think make the cut:

RequestRetries => MaxRequestRetries
  - Why not? Retries is already a count, Max does not add that much clarity.
RetryTimeout => RequestRetryTimeout
RetryTimeoutFn => RequestRetryTimeoutFn
  - Why not? Request prefix just starts to get unnecessarily descriptive.
    RequestRetryTimeout may be slightly clearer, but not compellingly so.
RequiredAcks => ProducerRequiredAcks
  - Why not? Only producing requires acks, so RequiredAcks is unambiguous
    (similar to RecordRetries, etc).

Everything else was less compelling.

I plan to push these as v0.11.0 within the day, and wait another day for any dissenting feedback before I tag v1.0. Also, #73 is easy and can go with v0.11.0.

[twmb]

All of the above, minus Balancers, was implemented in v0.11.0. This serves as rc2. Barring any further suggestions, 1.0 is imminent.

[twmb]

This has been released!