DOC: Don't hardcode config JAR version in migration guide
I foresee that we'll forget to update the version when we update the config library sometime in the future.
Here's the current doc:
"…you will need to ensure that`config-1.0.0.jar <http://mirrors.ibiblio.org/maven2/com/typesafe/config/1.0.0/>`_ is present on your classpath."
Here's the current doc:
"…you will need to ensure that`config-1.0.0.jar <http://mirrors.ibiblio.org/maven2/com/typesafe/config/1.0.0/>`_ is present on your classpath."
Leave a comment
on 2012-12-06 15:23 *
By Rich Dougherty
Or maybe we should hardcode it! Patrik has pointed out to me that we don't want the version to change anymore once we're working on 2.2. But we do want to change it when we update 2.1 any versions in the 2.1 branch.
If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc.
I'm not sure what the best solution is. We want something low overhead and we also want to make sure we don't forget to update these versions.
If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc.
I'm not sure what the best solution is. We want something low overhead and we also want to make sure we don't forget to update these versions.
on 2013-02-21 09:11 *
By Patrik Nordwall
To summarize, we have two options
1) hardcode everything in the migration guide, which makes it possible to include old migration guide in new version
2) use variables (and compiled code samples of new code), and only link to old migration guide in new version
I don't think we should do anything for 2.1.x, but something to decide for 2.2
1) hardcode everything in the migration guide, which makes it possible to include old migration guide in new version
2) use variables (and compiled code samples of new code), and only link to old migration guide in new version
I don't think we should do anything for 2.1.x, but something to decide for 2.2
I think we should hardcode it in the migration guides. They are not intended to change for each version.
not completely invalid
I agree that hardcoding in migration guide is the best solution, but as Rich pointed out: "If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc."
I agree that hardcoding in migration guide is the best solution, but as Rich pointed out: "If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc."
on 2013-03-15 08:36 *
By Patrik Nordwall
we don't need to hardcode scala version in "current" migration guide, but it must be fixed in migration guide for older versions, e.g. migration-guide-2.0.x-2.1.x.rst in master, otherwise that file will be wrong when we switch to 2.11.x
on 2013-04-03 05:54 *
By Patrik Nordwall
Assigned to set to Patrik Nordwall
Status changed from Invalid to Test