How to maintain go-service-* more easily?

Every time when there are updates on go-storage (especially after a GSP is approved), all the services should be updated correspondingly. Cases are:

This is very tiring and boring, especially when we are having more and more services. There may also be a repetition of work, e.g., update go-storage multiple times in a development cycle:

  1. go-storage update 1
  2. go-service-* update to master
  3. go-storage update 2
  4. go-service-* update to master
  5. go-storage release
  6. go-service-* update to the new release and also release

We may do this instead:

  1. go-storage update 1
  2. go-storage update 2
  3. go-storage release
  4. go-service-* update to the new release and also release

Actually, we did so: Implement GSP-97, GSP-109 and GSP-117 by JinnyYi · Pull Request #126 · beyondstorage/go-service-s3 · GitHub . But we didn’t establish a rule (like a release cycle?).
Another point is that bumping version can be done by dependabot. But can it automatically run make build for us? Even if not, this can be a hint in the release cycle.

Besides, we are using tracking issues to also track the implementation status of the services. The problem is: which services should be tracked?

If we track all services:

  • this is very heavy work
  • the tracking issue will need a long time to be closed
  • how to track effectively? We may lose track if not linked. But we may need to link many tracking issues when bumping the version of go-service-*

If we don’t track services, go-storage feature is useless without go-service-*.
However, even if we update services in time, what if a user uses a new version go-storage with outdated go-service-*? (Actually, this is a question that confused me for long and maybe we can open another post)

1 Like

Take connection string as an example: We added a new API in go-storage, and updated code generator. go-service-* should generate new code. If a user uses an old version of go-service-*, the API won’t work, but the user doesn’t know why.

On the other hand, the user cannot simply run go get -u all, since it is possible that some services are synced with latest go-storage, while others not. This intermediate status will be confusing.

I think it’s OK to only bump go-service-* after go-storage has been released. Maybe we need to release new versions more frequently?

Establish a rule is always a great idea. Can you start a GSP to resolve this problem?

Maybe it possible to run make build while dependabot sending new PRs that related to go-storage.

It’s a problem for me too.

Now I prefer to not track the service implementations. Instead, we can create the feature’s tracking issue in every single services (which could be implemented via go-community).

So, the whole process for new features will be:

go-storage side

  1. Discuss ideas with the community (pre-proposal)
  2. Sending proposal and get approved
  3. Creating tracking issues (in go-storage and every services)
  4. Update definitions / go-storage / go-integration-tests (only in go-storage)
  5. Release new go-storage (no need to wait for services)

service side

  1. Wait for go-storage releases (tracking issue has been created at the time that GSP approved)
  2. Services that not possible to implement this feature can close tracking issue with comments.
  3. Services that can implement will close the tracking issue after implement.
1 Like

It’s indeed a problem.

How about add var Version in go-storage, and save it in ervery services like GeneratedVersion. (we can update the version everytime we generate it).

We can warn the user it the version is not match.

1 Like

GSP-669: Feature Lifecycle by xxchan · Pull Request #669 · beyondstorage/go-storage · GitHub resolves most of the problems, except the version problem.

1 Like