Update guide or description of compatibility guarantees

[jawnsy]

Pull request #46 changes some flags, which is a breaking change unless users re-deploy using the Deployment manifest. I'd propose either:

• Adding a warning that breaking changes can occur, to set user expectations; or,
• Defining a support strategy (e.g. support both flags for some period of time, deprecating the old one, etc)

Prior to the linked pull request, the code looked like this:

gke-autoneg-controller/main.go

Lines 57 to 63 in 05c4b1c

	flag.StringVar(&metricsAddr, "metrics-addr", ":8080", "The address the metric endpoint binds to.")
	flag.BoolVar(&enableLeaderElection, "enable-leader-election", false,
	"Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.")
	flag.StringVar(&serviceNameTemplate, "default-backendservice-name", "{name}-{port}",
	"A naming template consists of {namespace}, {name}, {port} or {hash} separated by hyphens, "+
	"where {hash} is the first 8 digits of a hash of other given information")
	flag.BoolVar(&allowServiceName, "enable-custom-service-names", true, "Enable using custom service names in autoneg annotation.")

Afterwards, it now looks like this:

gke-autoneg-controller/main.go

Lines 62 to 70 in b8b9a87

	flag.StringVar(&metricsAddr, "metrics-bind-address", ":8080", "The address the metric endpoint binds to.")
	flag.StringVar(&probeAddr, "health-probe-bind-address", ":8081", "The address the probe endpoint binds to.")
	flag.BoolVar(&enableLeaderElection, "leader-elect", false,
	"Enable leader election for controller manager. "+
	"Enabling this will ensure there is only one active controller manager.")
	flag.StringVar(&serviceNameTemplate, "default-backendservice-name", "{name}-{port}",
	"A naming template consists of {namespace}, {name}, {port} or {hash} separated by hyphens, "+
	"where {hash} is the first 8 digits of a hash of other given information")
	flag.BoolVar(&allowServiceName, "enable-custom-service-names", true, "Enable using custom service names in autoneg annotation.")

Overall, the goal is just to ensure that users and developers have aligned expectations. Perhaps users should not expect stability given that we are pre-1.0. In this case, users upgrading from 0.9.8 to 0.9.9 will have to update their deployment manifests.

[rosmo]

We'll stabilize at 1.0, which should be soon - if the new release proves stable and correct.

[rosmo]

So, 1.0 is out. We will be adding new features (such as the continuous reconciliation), but next release will be 2.0. Any bugfixes will be ported back to 1.0. Hope this is sufficient?

[rosmo]

I think we're option for a more conservative approach, next would be 1.1.0. Any bugfixes would be 1.0.x.