Skip to content

[BEAM-806] update archetype poms in master#1169

Merged
asfgit merged 1 commit intoapache:masterfrom
dhalperi:beam-806
Oct 24, 2016
Merged

[BEAM-806] update archetype poms in master#1169
asfgit merged 1 commit intoapache:masterfrom
dhalperi:beam-806

Conversation

@dhalperi
Copy link
Contributor

Per the linked JIRA, maven release:branch did not do the right thing.

R: @aljoscha
CC: @davorbonaci

Per the linked JIRA, maven release:branch did not do the right thing.
@davorbonaci
Copy link
Member

LGTM.

Do we know why? I don't remember doing this myself.

@dhalperi
Copy link
Contributor Author

CC: @lukecwik @peihe

From Luke:

The problem with the previous version was that our archetypes were not being maintained, and it was incorrect to say that they were compatible across those ranges because of all the backwards incompatible changes

This is completely true, and the process of fixing it manually in master works. But this does not help the release process, which is specifically designed to use mvn release to do all updating of versions repository-wide.

@aljoscha
Copy link
Contributor

LGTM for master but it doesn't solve my problem with the 0.3.0-incubating release because the plugin does all the version juggling between 0.3.0-incubating-SNAPSHOT and 0.3.0-incubating. I could try working around that manually but I feel that a proper fix would be good there.

On a side note, it's somewhat strange that the release plugin pushes everything to git right-away without giving me a chance to correct things. (I know that this is documented in the release guide and I knew it when executing the command, but still...)

@asfgit asfgit merged commit 5d01184 into apache:master Oct 24, 2016
asfgit pushed a commit that referenced this pull request Oct 24, 2016
@dhalperi dhalperi deleted the beam-806 branch October 24, 2016 19:23
@davorbonaci
Copy link
Member

Totally agree that automatic pushes are not a great idea. There's a manual flag to disable them. It would be great if all this went through pull requests, but that appears to be non-standard. I'm hopeful we can improve this in the near future.

@dhalperi
Copy link
Contributor Author

At the same time, manual fixup of PRs is not reproducible across different committers or releases... a platonic release process would be fully automated. We ought to fix the process such that even if done in PRs we are not needing to do anything but rubber stamp; and we would catch breakages to the release process earlier. Maybe we can do some of this with the nightlies, like testing that we can run mvn release:prepare and that it compiles?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants