8000 Define development guide · Issue #52 · naver/scavenger · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Define development guide #52

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
junoyoon opened this issue Mar 13, 2023 · 14 comments
Closed

Define development guide #52

junoyoon opened this issue Mar 13, 2023 · 14 comments
Assignees
@junoyoon @kojandy @taeyeon-Kim @sohyun-ku

Comments

@junoyoon
Copy link
Collaborator
  • We didn't define development style yet surprisingly but used precisely defined editorconfig only.
  • Following guides are necessary.
    • Coding style
    • Branch / Merging policy
    • Release policy

Now.. it's the time.
@taeyeon-Kim
Copy link
Contributor

I just tried to release 1.0.4 and... I saw that I hadn't changed the version below... I thought I'd make a decision at this point.
https://github.com/naver/scavenger/blob/develop/build.gradle.kts#L7

allprojects {
    group = "com.navercorp.scavenger"
    version = "1.0.3"

@junoyoon
Copy link
Collaborator Author

Yes.. it's time to use gradle release plugin like (https://github.com/researchgate/gradle-release)

@junoyoon
Copy link
Collaborator Author
junoyoon commented Mar 14, 2023 •
edited
Loading

What about investigating and applying gradle release plugin? @sohyun-ku

@sohyun-ku
Copy link
Contributor

ok. I'm on vacation this week, so I'll check next week.

@junoyoon
Copy link
Collaborator Author

OK. Take your time and see u next week. :-)

@sohyun-ku
Copy link
Contributor
sohyun-ku commented Mar 21, 2023 •
edited
Loading

I think current release step like below

  1. make a release branch to modify version
  2. release → main PR
  3. make a TAG & Release new version at main

If we use gradle-release plugin, I think some features make problem.

• Creates a release tag with the current version.
• Commits the project with the new version.

First, if we run gradle release at release branch, tag is created at release bra 8000 nch.
Second, committed version is v1.0.1(new version) but created tag version is v 1.0.0(current version)

I think the above problems don’t follow 3. make a TAG & Release new version at main

Why don’t we use Github Actions instead of gradle-release-plugin?
Using a github action like below we can fire an event(ex. release, tag) when the main branch is pushed.

If I've missed anything, please tell me.

@sohyun-ku
Copy link
Contributor

@junoyoon @taeyeon-Kim @kojandy
#52 (comment) What about this?

@taeyeon-Kim
Copy link
Contributor

@sohyun-ku
Firstly, you are not on the release branch.
Here are the steps for the current release

  1. merge from develop to main (e.g. master merge for the v1.0.4 release #51)
  2. create a tag and create a release note at https://github.com/naver/scavenger/releases/new
  3. release

My worry is, when should I update the version listed in gradle?
If you decide on this part, it doesn't seem to matter whether you use actions or gradle-release-plugin.
It seems easier to apply with actions, so actions looks good.

@kojandy
Copy link
Contributor
kojandy commented Mar 23, 2023

I also think github actions might be a better solution as it can generate and upload all the release assets without manual intervention.

@sohyun-ku
Copy link
Contributor

My worry is, when should I update the version listed in gradle?

It's up to us to decide, but I think..

First step is create release/{version} branch and update version
Second step is release/{version} -> develop PR
Third step is develop -> main PR
Finally we create release(using github actions)

It's just my opinion, plz let me know what do you think.

@junoyoon
Copy link
Collaborator Author

I will describe my thought this weekend.

@junoyoon
Copy link
Collaborator Author

I think we can create release branch from master to activate the github action to release.
and no merge back this branch to master. just drop it.

what about this scheme?

@sohyun-ku
Copy link
Contributor

Sounds good :)
Then I'll add github actions when pushed release branch.

@sohyun-ku sohyun-ku mentioned this issue Mar 28, 2023
Merged
@sohyun-ku
Copy link
Contributor

Release policy created in #55.

1. develop -> main PR
  - If we want to release, PR title should be start 'release' and include ${version}
  - ex) PR title - Release v1.0.5
2. If PR is merged, trigger tag github action
  - Remove SNAPSHOT and commit to next version by gradle-release plugin
  - Create Tag in this action
3. If a tag is created, trigger create a release github action
  - Create Release in this action

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@junoyoon junoyoon

@kojandy kojandy

@taeyeon-Kim taeyeon-Kim

@sohyun-ku sohyun-ku

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@junoyoon @kojandy @taeyeon-Kim @sohyun-ku
0