[discuss] Release what we have as 1.0.0?

[igalic]

in the past couple of weeks we've added loads of new features and I was wondering if we should branch off here, and release the current master as 1.0.0

That way we could focus on getting 2.4 support (#337) in.

I'm not sure if should even tie this in with a completely new configuration backend (#477), or if that will lead to a second-system effect.

Comments welcome.

[blkperl]

Do any of the new features break backwards compatibility? If not why not just release a 0.0.10 and save 1.0.0 for a rewrite or breaking changes in 2.4 compatibility.

I do think its time for another release though 👍

[igalic]

I think it would be possible to do 2.4 with reasonable effort on the base that we have now.

We could, indeed, safe 1.0.0 for rewriting the backend from erb to types with two providers (httpd24 and httpd22).

I suggest we wrap up the current pulls and release what we have as 0.0.10. (I still haven't managed to sort out #373)

[tampakrap]

In case it matters, I have patches for openSUSE/SLES and Gentoo support for which I plan to submit PRs soon (still testing stuff).

[antaflos]

Just so that this doesn't get overlooked: it should be version 0.10.0, not 0.0.10.

Although I am not sure if all changes since 0.9.0 are backwards compatible in the SemVer sense. The default behaviour of certain features has definitely changed somewhat (off the top of my hat, #488, #491, #490). Then again I don't know much about the intricacies of release management.

[igalic]

@antaflos thanks for the reminder! It should, indeed, be 0.10.0. Because, even though some of the changes may break backwards compatibility, this is semver < 1.0.0, so we're cool, it means free for all, go nuts (no not really ;)

@tampakrap that's cool! But also nothing wrong in shipping those in 0.11.0.

Open Source, release early, release often, and all that…

[Aethylred]

I'm torn on this, semantic versioning says we shouldn't increment Major unless theirs an API breaking change, on the other hand we had that happen around 0.6.0. A better call would be to put 1.0.0 up if we think that this module is ready for production. A declaration that this module is robust for regular usage.

I do think we should clock over to 1.0.0 before getting serious on the Apache 2.4 compatibility merges.

[antaflos]

I think before a 1.0.0 release can be made the module should really have support for multiple rewrite rules, as in #373. The functionality of mod_rewrite is one of Apache's most (mis)used features and I believe a Puppet module that manages Apache is not complete without proper support for that.

I know we can use custom_fragment for anything not directly supported but it is more of an ugly workaround and has its own problems still (issue #450 comes to mind).

[Aethylred]

@antaflos ...so you're putting forward that there should be a milestone discussion about what features should be completed to bump to 1.0.0?

[antaflos]

@Aethylred I think that would be beneficial, yes. But as I said, I have no experience in release engineering or related concepts. I just think you can't designate this module as 1.0.0 when an, in my opinion, major feature like proper mod_rewrite support is missing.

[blkperl]

I've made a release PR for 0.10.0 #507. Please review and comment.

[blkperl]

Now that 2.4 support is in master it's time to decide if we want a 0.12.0 release or 1.0.0 release.

[inetdavid]

Do you want the version numbers to follow Semantic versioning? If so, you should only update the major (first) number when a new version breaks older functionality. You update the second number when new functionality is provided.

David Schmidt
[email protected]

On Feb 6, 2014, at 3:26 PM, William Van Hevelingen [email protected] wrote:

Now that 2.4 support is in master it's time to decide if we want a 0.12.0 release or 1.0.0 release.

—
Reply to this email directly or view it on GitHub.

[igalic]

one of the definitions of semver is that < 1.0.0 all bets are off

[hunner]

@blkperl @igalic Thanks for working on the releases!

Even though 2.4 support is in master, I think we can still do a 1.0.0 off of that and should make a 1.0.x branch; bugfixes PRs (for 2.4 support and anything else basically) can go in that branch to prepare it for release. Branch master can be where we target features for an eventual 1.1.0 release.

So we'll be able to release 1.0.0 in the next week or so with the updated README and current feature set. Maybe we could try out the "milestones" thing and make a roadmap for what will eventually go in 1.1.0? And if we're really good, we could figure out what needs to happen to make 2.0 rock.

[igalic]

Hmmmm… that still leaves us an option where we can, essentially, reimplement the whole thing to be more modular…

[hunner]

@igalic Where do you think you'd like to discuss that? Github issues seem awkward. Jira issues seems like the correct answer, but also awkward. We could start a DESIGN.md in the master branch with PRs or something... ideas?

[igalic]

Google Docs? IRC? Something?
DESIGN.md might be less worse.

[chelnak]

Hello! We are doing some house keeping and noticed that this issue has been open for a long time.

We're going to close it but please do raise another issue if the issue still persists. 😄