Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-27 Thread Alex Heneveld
We jump through quite a few hoops to ensure rebind works, including current PR [1]. (I might feel differently if I haven't just spent too long making those hoops.) Code will be able to be simplified quite a bit in this area if we disallow the so-called "anonymous bundles" - but feels premat

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-27 Thread Thomas Bouron
Fair points Alex, you are absolutely right. Although, I still think that forcing to have `bundle:` now in a bom is a better way: It will be annoying for users but easy to fix, whereas the alternative means that it Brooklyn **will be broken on restart/rebind** which is a clear no-go from my point o

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-27 Thread Alex Heneveld
Thinking about it I'm not convinced that breaking users blueprints is the best way to update their mental model. With a shift to use the CLI with catalog.bom in root and updating exemplar projects, and updating UI to reflect bundles, I expect we'll achieve this in a less disruptive way. At

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-27 Thread Thomas Bouron
+1, this sounds sensible to me too. I also vote in favor of making this a breaking change. With 1.0.0 coming, this is the perfect time to do it. Best. On Fri, 27 Oct 2017 at 08:06 Geoff Macartney wrote: > +1 to your suggestion Aled. Also I'd side with making it a breaking > change, I prefer f

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-27 Thread Geoff Macartney
+1 to your suggestion Aled. Also I'd side with making it a breaking change, I prefer forcing that mental model. On Thu, 26 Oct 2017 at 13:12 Aled Sage wrote: > Alex, > > I say we break it - force the user to have the correct mental model for > 1.0.0! > > It's a simple one-line addition to fix

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-26 Thread Aled Sage
Alex, I say we break it - force the user to have the correct mental model for 1.0.0! It's a simple one-line addition to fix a given .bom file. We should obviously ensure that historic persisted state continues to work. --- Also note that our deprecation warnings are too hidden. For example

Re: [PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-26 Thread Alex Heneveld
Absolutely. Question is whether we should deprecate or make it a breaking change. Deprecating feels right, though I think it would mean we can't actually remove until 2.0 ? Best Alex On 26/10/2017 12:06, Aled Sage wrote: Hi all, I propose we make it mandatory to specify the bundle id and

[PROPOSAL] catalog bundle id:version mandatory in v1.0.0

2017-10-26 Thread Aled Sage
Hi all, I propose we make it mandatory to specify the bundle id and version (currently it is optional). I think we should do this asap, before 1.0.0 is released. This is a breaking change - it will require users to add a `bundle: ...` line to their .bom files (if they are not supplying the m