1.1.0 Release

[hdoupe]

We are planning to do another PolicyBrain release in the next 2 to 3 weeks (around October 27). This is part of a larger goal to release more often. This allows us to add changes to PolicyBrain in smaller increments and work towards a smoother release process.

The three goals for this next release are:

1. Put OG-USA back on TaxBrain ( Steps for putting OG-USA back on TaxBrain #539 )
2. Front-end clean-up ( @GoFroggyRun would you mind listing the issues that you would like to resolve by the next release)
3. Increase test coverage and quality ( Post 1.0.3 release push for more automated testing #699 )

If anyone would like to add another feature in this release, then we can discuss this in the comments section below. We want to bite off a manageable chunk of work so that we can get the release off on schedule. However, I am completely open to discussing the addition of new features or changes to this release.

Does anybody have an idea for what the the tag should be for the next release? Does re-instating a feature constitute a "minor change" as defined at semver.org?

[martinholmer]

@hdoupe said:

We are planning to do another PolicyBrain release in the next 2 to 3 weeks (around October 27).

What version of Tax-Calculator will the next PolicyBrain release use?
Will it use 0.11.0 or 0.12.0 (which could be make available soon)?

[martinholmer]

@hdoupe asked:

Does anybody have an idea for what the the tag should be for the next release? Does re-instating a feature constitute a "minor change" as defined at semver.org?

Because PolicyBrain doesn't really have a public API that is used by client projects, it is not obvious how to apply the principles of semantic versioning. There are two logical alternatives:

1. If you view the public users of TaxBrain and CCC as "client projects", then any substantive change in the capabilities of TaxBrain or CCC would be a "major" change.

2. If you don't want to be that expansive about what constitutes a "major" change, then you could say any substantive change in TaxBrain or CCC capabilities would be a "minor" change. Certainly calling a substantive change in capabilities a "bug fix" makes no sense.

So, version 1.0.3 does not offer the OG-USA capability and does not offer distribution and difference tables that use AGI bins, but the next version will offer both of these capabilities.

So, using the first perspective, the next version would be 2.0. In this approach, dropping the third "bug fix" number probably makes sense. In this case, if the next version after the next does not add any new capabilities (but fixed bugs), it would be numbered 2.1. Or, if it did offer new capabilities, it would be 3.0.

On the other hand, using the second perspective, the next version would be 1.1.0. In this case, if the next version after the next does not add any new capabilities (but fixed bugs), it would be numbered 1.1.1 Or, if it did offer new capabilities, it would be 1.2.0.

To me, the second perspective seems the most sensible way to apply semantic versioning to PolicyBrain.

So, if others agree, the next release would be PolicyBrain version 1.1.0.

[hdoupe]

@martinholmer asked

What version of Tax-Calculator will the next PolicyBrain release use?
Will it use 0.11.0 or 0.12.0 (which could be make available soon)?

I think PB will remain on Tax-Calculator 0.10.2 for this release. 0.11.0 requires some minor changes in the TaxBrain/Tax-Calculator interaction. If there's time, I may tackle this, but I don't think there will be time. In the following PB releases, the CPS will be added and that will require a TC version change to 0.12.0+. So, I plan to wait until then to change the version. Does this sound sensible to you?

[hdoupe]

@martinholmer I think I like the second perspective more. I think using the first perspective would send us pretty high in the version count in the next year or two. However, this isn't too uncommon with web applications (the Firefox version that I'm using is numbed 56.0).

I'm not sure what would constitute a major change in the second perspective. Would that involve removing/adding an app?

Defining a public API is something that we should start thinking about. I'm not really sure how to define our public API right now. TC's pubic API is pretty intuitive since users directly call its methods. PB's public API is harder to define since it is really only called by the web. The only other interactions that it has with applications outside of the web are the OSPC python libraries like Tax-Calculator. At some point, a separate issue needs to be opened to discuss this further.

[GoFroggyRun]

@hdoupe asked:

would you mind listing the issues that you would like to resolve by the next release

Sure. Here's a (tentative) list:

• Issue Fix mislabeled "Macro Elasticities Simulation" button #673 and Eliminating year selection button for "Macro Elasticities Simulation" #683 (fixed via PR Rename macro elasticity label and remove dropdown menu in its result page #684 )

• Issue Print and Copy and CSV of Built Table are not correct #629 (fixed via PR Correct build table names for "Copy", "CSV" and "Excel" #675 )

• Issue Questions about the Excel download button on the TaxBrain results page #678 (fixed via PR Remove "Excel" button for both tables #694 )

• Issue TaxBrain file-upload page needs updating #500 (fixed via PR Enhance file upload preview #701 )

• Issue Revenue table (Print, etc.) buttons disappear when selecting different (Reform, etc.) table #613 (shaky)

• Issue Macro_elasticity results page csv output requires sign in #616 and Macroeconomic_elasticity results page share and print buttons broken #617 (shaky, I might remove those options for the moment if can't have a complete fix)

[hdoupe]

Thanks @GoFroggyRun. I'll start a milestone for this release.

[hdoupe]

PR's #722 and #724 are on the test app. I plan to push 1.1.0 to production at 4 PM today if nobody has any objections.

@MattHJensen @GoFroggyRun

[MattHJensen]

I plan to push 1.1.0 to production at 4 PM today if nobody has any objections.

Will this cause downtime?

[hdoupe]

Ah, good point. The downtime shouldn't be too bad. The front-end update would take about 5 minutes. The node updates would just decrease computing power for half an hour or so. I would do 3 or 4 nodes at a time. So several nodes would be up throughout the update.

However, today is not a good day for downtime. Further, if it takes longer than expected then that would not be good. I'll do the update tonight around 9 or 10 PM. Hopefully, we will be safe then.

[GoFroggyRun]

@hdoupe said:

I'll do the update tonight around 9 or 10 PM.

Sounds reasonable to me. +1

[hdoupe]

Release 1.1.0 is complete. Closing