search

eclipse-ee4j / ee4j

Eclipse EE4J Top-level Project and community related issues
http://www.eclipse.org/ee4j
Other
276 stars 44 forks source link

Question: How did we release 1.0.6, but the code is still at 1.0.6-SNAPSHOT? #62

Closed kwsutter closed 4 years ago

kwsutter commented 4 years ago

Something seems out of whack... We have released version 1.0.6 of the parent pom, but the actual file still has 1.0.6-SNAPSHOT. The code should be at 1.0.7-SNAPSHOT, correct? And, how did we get into this situation in the first place?

pzygielo commented 4 years ago

I tried to show it in #58 :smile:

bshannon commented 4 years ago

Did someone forget to merge in the release branch after doing the release?

bshannon commented 4 years ago

Yup, the 1.0.6-RELEASE branch needs to be merged and then deleted. Don't we have these instructions written down somewhere?

kwsutter commented 4 years ago

I tried to show it in #58 😄

Looks like you shouldn't have given up so easily... ;-) You were on the right track...

kwsutter commented 4 years ago

Yup, the 1.0.6-RELEASE branch needs to be merged and then deleted. Don't we have these instructions written down somewhere?

Probably two issues here... 1) The expected process is not documented sufficiently. And, 2) other teams don't use this separate branch idea. Instead, as part of the jenkins build, the pom is automatically updated with the next SNAPSHOT version. I know this is the way that MicroProfile does it, so there are multiple ways of advancing master to the next SNAPSHOT...

kwsutter commented 4 years ago

Taken care of now via PR #63 . Thanks for the discussion!

bshannon commented 4 years ago

To be clear, the reason for the separate branch is that it allows you to correct mistakes. You can push something to the staging repo, create the branch, do some testing, and then discover that it's not right after all. You can then destroy the branch, destroy the staged artifacts, and do it all over again, and the "release" job does all of this for you so you can keep rerunning the release job as many times as you need to until you get it right.

If the release process had updated the repo, you then would have to commit a "rollback" change and try again. It leaves the repo full of your mistakes.

Obviously either way will work, with different advantages and disadvantages.