Skip to content
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

updating changelog and prepping metadata for release as 1.0 #13

Merged
merged 5 commits into from Feb 22, 2016
Merged

updating changelog and prepping metadata for release as 1.0 #13

merged 5 commits into from Feb 22, 2016

Conversation

danzilio
Copy link
Member

@danzilio danzilio commented Feb 4, 2016

No description provided.

domcleal
domcleal reviewed Feb 4, 2016
View reviewed changes
CHANGELOG.md
- Backwards compatibility with Puppet >= 3.4
- Ability to select the `letsencrypt` install method using the `install_method` parameter. Current supported options are `package` and `vcs`.
- The `manage_install` parameter now lets the user select whether they want to manage the installation of `letsencrypt` with this module.
- The `configure_epel` parameter now lets the user manage the EPEL repository on EL systems.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps note that the epel module's needed for this to work.

@domcleal
Copy link
Contributor

domcleal commented Feb 4, 2016

Worth noting either under install_method or Breaking that the default behaviour's changed on some OSes to install the package rather than from source.

@danzilio
Copy link
Member Author

Hey @domcleal, sorry I've let this sit for so long! I just updated CHANGELOG but I also decided to change the default install_method for RedHat back to vcs. I just think that setting install_method to package for all of RedHat is overly broad when the letsencrypt package is not available in core RedHat repositories yet. I'm torn between leaving the default as vcs or changing the default for manage_epel to true to accommodate. I think the least intrusive means is to just leave the default of vcs. Thoughts?

@domcleal
Copy link
Contributor

Yeah, I understand your reasoning and desire to keep it working out of the box, I can't argue with that.

Being a chronic software packager I dislike the vcs installation, so I'd prefer to force the user to choose between using a VCS installation or configuring EPEL (by setting manage_epel or using another module) when installing the module.

I can't help but think the majority of users would prefer to enable EPEL over using a VCS installation, so setting manage_epel to true by default sounds reasonable.

@danzilio
Copy link
Member Author

Yeah I'm not particularly a fan of the vcs method, it was mostly a stopgap until packaging became prevalent. Now that you mention it, I think you're right that the majority would prefer to configure EPEL over the VCS install...

Setting manage_epel to true means we should make epel a hard dependency in metadata.json...

@domcleal
Copy link
Contributor

Setting manage_epel to true means we should make epel a hard dependency in metadata.json...

Yes, quite probably - if it's true by default then it should probably always be installed.

@danzilio
Copy link
Member Author

OK! Just pushed those changes!

@domcleal
Copy link
Contributor

I think that's OK, thanks @danzilio. 👍

@danzilio
Copy link
Member Author

Ok! I'll let the build finish and then push the release! This is a big change so I'm also going to send an email out to the puppet-users mailing list announcing the release.

danzilio added a commit that referenced this pull request Feb 22, 2016
@danzilio
Merge pull request #13 from danzilio/release_1.x
1474da4 
updating changelog and prepping metadata for release as 1.0
@danzilio danzilio merged commit 1474da4 into master Feb 22, 2016
@danzilio danzilio deleted the release_1.x branch February 22, 2016 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@danzilio @domcleal