RFC Adopting a major release policy

[maxime-rainville]

Read our Revising our approach to major release blog post before commenting on this RFC. This will help to contextualise the discussion.

This document does not include details about specific features, many dependencies or design processes (including any topics about future CMS UI/UX, high-demand feature requests, or long-standing functionality issues).

Problematic (a background)

We painted ourselves into a corner in 2019 when we foreclosed any quick Major release.

All the dependencies we rely on follow a major releases cycle that leads them to release new majors every 2-3 years.

More and more of our time is spent on upgrading Silverstripe CMS dependencies. Many of the APIs from those dependencies are directly or indirectly included in our own API. This means that we have to choose between respecting our API contracts and adding support for the latest major. We’ve broken our semver commitments over the last few years to upgrade dependencies (PHPUnit, Swiftmailer, oEmbed).

Our current approach is meant to provide certainty to project owners, but actually increases uncertainty because every few minor releases we end up shipping some breaking changes. Project owners can’t effectively plan how much work will be needed to upgrade between minors.

It also increases the amount of work we have to do, because we jump through hoops to make our breaking changes more palatable. E.g: Dual support for PHPUnit 5.7 and PHPUnit 9.5.

Broad approach

More frequent smaller major releases at regular intervals will allow us to upgrade our dependencies more effectively. This will negate the need for us to do minor releases with breaking changes because we will be able to push all those changes to the upcoming major release.

This will also benefit Silverstripe CMS project owners by enabling them to plan their upgrades with greater confidence.

Major releases will focus, in descending order of priority, on:

• Upgrading third party dependencies
• Removing/cleaning up deprecated APIs
• Implementing architectural changes that can not reasonably be introduced in a minor
• Reviewing our commercially supported module list

New features will mainly be delivered via ongoing minor releases.

Key objectives

• The updated policy should allow owners of Silverstripe CMS projects to clearly know when the next major release is scheduled so they can plan their upgrades.
• The updated policy should clearly communicate the expected support timeline for older major releases.
• Our releases cycle is aligned to the PHP releases cycle.
• No more than two major releases are supported at once.
• New minor releases are only targeted towards the latest major release.

Assumptions

• Minor/major PHP releases occur every year in November. PHP releases are actively supported for two years followed by one year of limited support.
• Our latest major release line can be aligned with the latest PHP version.
• CMS4 is still architecturally sound and we don’t need to do any substantial changes to it.
• Symfony releases new minors every 6 months. Symfony majors are under active development for two years and are actively supported for 3 years after that.
• Ongoing support for older majors will not be detrimental to us adding new features to the latest major.
• We can deliver major dependency upgrades more effectively if we are allowed to break APIs.
• Using supported dependencies minimise our security risk exposure by ensuring we have access to the latest patch.

Definitions

• “Active development” means that we are working on adding new features.
• “Full support” means that we accept bugs at all levels of impact and push regular patches. No new APIs.
• “Limited support” means that we are only addressing critical security vulnerabilities and critical bugs.
• “End-of-life” means that a release is no longer supported and that no bug fix will be provided even for critical issues.
• “Fixed dependencies” are dependencies that Silverstripe CMS relies on and whose APIs are partly included in our own.
• “Non-fixed dependencies” are required by Silverstripe CMS’s internal logic but are not directly exposed via the Silverstripe CMS API.

Policy proposals

• New majors are released every two years in the first quarter of odd years. (2023, 2025, 2027, etc)
• At launch, CMS majors will be compatible with actively supported PHP versions.
• PHP versions in limited support will not be supported at launch by new majors.
• At launch, CMS majors will only track the latest stable Symfony major release.
• At launch, CMS majors will aim to track the latest stable release of all its fixed dependencies.
• For each major release line, Silverstripe CMS will identify which dependencies it considers a fixed dependency.
• A CMS major release line will not add support for new major releases of fixed dependencies even if the currently used version is EOL. The only exception is if the upgrade is necessary to fix a high importance bug or security vulnerability.
• We’ll only support 1 major release line of each fixed dependency.
• Non-fixed dependencies may be upgraded to new major releases or swap out altogether within a CMS release line.
• In between major releases, we will aim to add forward compatibility for the latest PHP release.
• Minor releases only occur against release lines in active development.
• Older major release lines go out of active development once a newer major is released.
• Older major release lines will have full support while there’s an actively supported PHP version they are compatible with. (1 year full support)
• Older major release lines enter limited support once all the PHP versions they target are in limited support or EOL. (1 year limited support)
• Older majors go EOL once all the PHP versions they target are EOL.

Practical implication

• CMS4 goes out of active development in December 2022 and will be actively supported until December 2023. It will then enter a period of limited support lasting until December 2024.
• CMS5 will be released in the first quarter of 2023 and will support PHP8.1 and PHP8.2, but not PHP8.0 which will be in limited support by then.
• CMS5 will use Symfony ^6.2 and will never support Symfony 7.
• CMS5 will be updated in the first quarter of 2024 to add support for the next version of PHP.
• Active development for CMS5 would cease in December 2024. It will be supporting PHP8.1, PHP8.2 and PHP8.3.
• CMS5 will be EOL when PHP8.3 is EOL in December 2026.
• CMS 6 is released in the first quarter of 2025.

Transition to a release policy for Silverstripe CMS 4

• Support for new Symfony versions will not be added to CMS 4.
• PHP8.1 will be the last PHP version supported by CMS 4.
• Dual GraphQL v3/v4 support will never be removed from CMS 4.
• Dual PHPUnit 5.7/9.5 support will never be removed from CMS 4.

Questions

Release management can be a wide ranging topic with lots of implications. When replying to the RFC, please focus on these questions so we can keep the discussion on track.

Release Lifecycle

• Do we want to extend the “limited support” of old major's so people can choose to skip Majors? E.g.: Upgrade from CMS4 to CMS6 bypassing CMS5?
• Is there a preferred major release cadence? What would be the rationale for your suggestion?Do we want to reduce the support period for old Majors to 1 years?

Dependency management

• When does a third party library become part of the CMS API?
• When we subclass their class (e.g.: SapphireTest)?
• When we expect a parameter of a specific type?
• When we return an instance of a class?
• How do we decide which dependencies are “fixed dependencies”? Do we need an objective criteria or can we do it just by fiat?
• Do we want to perfectly track Symfony releases? This would mean releasing in even years rather than odd years.

Definitional issue

• How specific do we want to be with “easy to upgrade”?
• What does “full support” mean in the context of older majors? Do we need to clarify it more?

Implementation concerns

• Assuming PHP versions are released in November and we release support for it around March, that gives us around 3 months to add support for new PHP versions. Are we happy with that? Do we need more flexibility?
• Does this policy need to specify beta/alpha release period for new majors?
• How do we support community module maintainers to migrate their module to the next major release? What are some of the risks if community modules can not be updated to the latest major promptly?

Note about the RFC process

• This RFC is not about CMS5 feature development. Once the RFC is accepted in one shape or another and we know when CMS5 is meant to drop, then we will have a follow up card to decide what needs to be in CMS5.
• Comments and feedback from the community will be taken into consideration by core committers, before decisions are then made by core committers.
• The RFC will be followed by a PR to add the major release policy to our doc. The policy will be formally adopted once the PR is merged.Planning for the next major release will begin once the policy is adopted.
• Structuring our release timing aligns with our larger strategy of making the upgrade to newer versions easier. Following the adoption of a release timing policy, we will continue to create and adopt processes that improve the predictability and reliability of upgrades.

Comment submission deadline

1st July 2022

Related

• Symfony support policy RFC (probably invalidated by this RFC)
• Symfony - The Release Process
• PHP support timeline
• Symfony support timeline
• Silverstripe CMS's current release process
• What is semantic versioning?

Indicative timeline

This is just for illustration purposes. It’s not necessary what we are going to do.

Pull request

• Add new major release policy to doc developer-docs#54

@silverstripe/core-team

[emteknetnz]

Do we want to extend the “limited support” of old major's so people can choose to skip Majors? E.g.: Upgrade from CMS4 to CMS6 bypassing CMS5?

Looking at the indicative timeline chart, the proposed limited support of 1 year seems like it already allows this, e.g. CMS limited support goes to the start of 2025, the same time that CM6 is released

Is there a preferred major release cadence? What would be the rationale for your suggestion? Do we want to reduce the support period for old Majors to 1 year?

A two yearly cadence seems best to me and is my preference

A once yearly cadence seem much too fast and would add in too much upgrade overhead for all parties IMO.

An every 3 years cadence also seems somewhat reasonable, it would provide more stability so projects are likely to benefit due to the reduced ongoing upgrade cost, though that may be offset by a greater upgrade cost when it does need to be done. From my perspective as Silverstripe maintainer, a three yearly upgrade cadence may end up boxing ourselves in with the inability to upgrade fixed dependencies. The wider software community has adopted a more frequent major upgrade schedule, so we'd likely resort to the sminnee/phpunit type of forks to keep old dependencies functional.

How do we decide which dependencies are “fixed dependencies”? Do we need an objective criteria or can we do it just by fiat?

I feel we may just have to make judgement calls on a case by case basis here. Guzzle would be a good example. We recently had to upgarde from v6 to v7 for PHP 8.1 compatibility. However because it's a popular library for making HTTP requests, it's fairly reasonable to expect some projects to be using the dependency in their project code.

When does a third party library become part of the CMS API? When we subclass their class

Yes - SapphireTest is a good example, and while it wasn't quite a API breaking change for projects because of the dual support, if you wanted to use PHP 8 then you were forced to upgrade project code.

... when we expect a parameter of a specific type / return an instance of a class

Yes - By definition that's an API change, you're parameter/return type is a different class

Do we want to perfectly track Symfony releases? This would mean releasing in even years rather than odd years.

I'd say probably not. The benefits of being aligned are we get the latest and greatest. The downside is that we're missing out on a years worth of bugfixes. Symfony is a building block and you just want things to work, so I'd prioritise stability over new features here.

How specific do we want to be with “easy to upgrade”?

I don't particularly like "easy to upgrade" for a couple of reasons.

Firstly it's a subjective term, what I personally find easy, a non-technical product owner may find highly annoying. Someone will end up disappointed because we said it would be easy and their experience was different.

Secondly, I feel it steers us away from making any innovative changes. For instance if we simply called the 4.12 release 5.0, well that would be easy to upgrade, though we're greatly limiting how much can be delivered.

I think we're better off saying something along the lines of "We'll provide a clear upgrade path" and then support it with documentation and possibly code-writing tools

What does “full support” mean in the context of older majors? Do we need to clarify it more?

Possibly change the definition as follows:

“Full support” means that we accept bugs at all levels of impact and push regular patches. No new APIs.
->
“Full support” means that we accept bug fix pull-requests and do patch releases. No API modifications.

Assuming PHP versions are released in November and we release support for it around March, that gives us around 3 months to add support for new PHP versions. Are we happy with that? Do we need more flexibility?

I think 3 months should be fine, though it's possibly a little tight. I was heavily involved with both the PHP 8.0 and PHP 8.1 upgrades.

PHP 8.0 was hard because we were still using phpunit 5.7 which was way out of date by that point so we needed to update everything to phpunit 9.5. If we had the major release policy proposed here this would not have been anywhere near as painful.

PHP 8.1 was even harder because of the deprecation warnings thrown when passing null to native php functions. I'd be surprised if we get something quite that gnarly again, and we did complete the development within a 3 month window. Worst case scenario is we don't support the latest PHP version at launch and have to release it during the first minor release likely 6 months later, that shouldn't be the end of the world.

Does this policy need to specify beta/alpha release period for new majors?

I think it should for the beta only. Perhaps a 1-month beta? In practice that would mean that all fixed dependencies would need to be upgraded and probably also PHP supported added, so I wouldn't want to make it too long or it takes away development time. Alpha's we should release, though I don't see much benefit in predictable timeframes given anything can change.

How do we support community module maintainers to migrate their module to the next major release? What are some of the risks if community modules can not be updated to the latest major promptly?

Main risk is that "easy to upgrade" goes further out the window, angering project maintainers. Project will resort to using forks of modules if only to add "silverstripe/framework": "^4 || "5" to the modules composer.json. Community modules with existing unit tests are easier to support as we can provide them a free GitHub Actions CI config and pull-request so that their module is tested being installed with both CMS 4 and 5 to validate things still work. Modules without unit tests will require more in the way of manual validation.

--

Asking my own question here - what Silverstripe modules are bound by this? All of the "supported" ones? Or only the core locked-stepped ones (framework, cms, asset-admin, etc), or core-locked stepped + a selected group of high used ones e.g. elemental?

[jakxnz]

I think we're better off saying something along the lines of "We'll provide a clear upgrade path" and then support it with documentation and possibly code-writing tools

👍🏻

[jakxnz]

I'm a big fan of this. Would be really helpful to have a cadence of releases, and some quality of life improvement around anticipating releases.

Do we want to extend the “limited support” of old major's so people can choose to skip Majors? E.g.: Upgrade from CMS4 to CMS6 bypassing CMS5?

Feels moot to me; like something we should respond to (rather than pre-empt) if users are leap frogging upgrades.

Is there a preferred major release cadence? What would be the rationale for your suggestion?Do we want to reduce the support period for old Majors to 1 years?

Applying Symfony's 2-year cycle as a reference class feels valid to me. Hard to say without experiencing the rate of progress. Based on how I see the framework used in the market, 2 years feels like it aligns well with perceived ROI.

When does a third party library become part of the CMS API?

When it is needed to fulfil the requirements of the framework.

When we subclass their class (e.g.: SapphireTest)?

Subclassing principles/consequences don't feel like a concern of a release policy. Seems more a concern of architecture practices.

How do we decide which dependencies are “fixed dependencies”? Do we need an objective criteria or can we do it just by fiat?

Feels like something that would best be defined as part of authoring the policy. My initial sense is a fixed dependency is anything that can't be substituted without changing the core philosophies of the framework design.

Do we want to perfectly track Symfony releases? This would mean releasing in even years rather than odd years.
Definitional issue

Am I correct that this isn't actually "years apart", this is just a few months apart? If so, I can't see any immediate practical benefits to this. My personal preference is to "perfectly track." Or in real-world terms, develop framework major releases during pre-release stages of Symfony major release; because it improves the perception of framework as a leader in expertise.

i.e Do we want to be seen as "on the ball" or "a bit behind"? There are valid reasonings for either, but my personal preference is to be seen as a knowledge leader, and my personal experience is that tools that are "on the ball" give this perception.

Assuming PHP versions are released in November and we release support for it around March, that gives us around 3 months to add support for new PHP versions. Are we happy with that? Do we need more flexibility?

Given the nature of PHP features, and the complexity of demands in the climate, I would propose this needs to be in flux. The minimum PHP version could be decided by consensus amongst the core team, as per the needs of the community, with some clear signals for how decisions are determined.

Does this policy need to specify beta/alpha release period for new majors?

No, but it would be good if it gave indicative timing of "development" and "stability" windows, as well as defined practices around when and how the community will be notified of these, so they can best participate.

How do we support community module maintainers to migrate their module to the next major release? What are some of the risks if community modules can not be updated to the latest major promptly?

As per @emteknetnz 's comment; providing a "clear upgrade path" would be a great start. Module maintainers and framework users have the same requirements in this area. They both need to be able to trust that upgrading will be tennable, and they both need to anticipate the benefits and timeline of upgrading. Alonside that, we would ideally be supporting the community with awareness and engagement, to cultivate enrollment and autonomy. Anything beyond awareness, trust-building, signposting, and reference-material feels beyond the scope of what a policy and its practices can achieve.

[lozcalver]

Do we want to extend the “limited support” of old major's so people can choose to skip Majors? E.g.: Upgrade from CMS4 to CMS6 bypassing CMS5?

Looking at the indicative timeline chart, the proposed limited support of 1 year seems like it already allows this, e.g. CMS limited support goes to the start of 2025, the same time that CM6 is released

The issue is that there’s no overlap. If CMS4 is supported until December 31st 2024 and CMS6 is released “Q1 2025” then there’s a period of a couple of months (ish) where you’re running unsupported software without being able to upgrade yet. Even if we release alphas/betas earlier, there’s still not much of a window in which to get upgrades done. If we do want to support skipping releases I think we’d need to offer, for example, at least 3 months of limited support for CMS4 after CMS6 has been released. Effectively that means extending CMS4 support for another 6 months.

I definitely think it’s worth considering, but it does mean a period of supporting 3 releases at once, and developers would have double the upgrade work. Worth mentioning we wouldn’t want to offer any tools/documentation for a 4 -> 6 upgrade, you’d have to go via 5.

Is there a preferred major release cadence? What would be the rationale for your suggestion?Do we want to reduce the support period for old Majors to 1 years?

I don’t think we should offer any less than 2 years for the support period. If we extend this to 30 months (2.5yrs) for the above “overlap” then we’d still be within PHP’s support window for the latest stable PHP version at release. If we extend to 3 years of support, then developers may have to upgrade their PHP version before the end of the support period - not necessarily a problem, just an observation. Given this and Symfony’s release cadence, I think either the proposed release policy or a very similar one with a slightly extended support period would be best.

Do we want to perfectly track Symfony releases? This would mean releasing in even years rather than odd years.

I don’t think this matters too much, looking at the 6.x release line if we’d release CMS5 in Q1 2022 we’d be using Symfony 6.0, if we release in Q1 2023 we’ll be using 6.2. Either way we’ll end up on 6.4 LTS for most of the lifecycle of CMS5, and by releasing the “opposite” year to Symfony (unless I’m reading things wrong) I think we actually gain a year’s worth of bug fixes/features.

How specific do we want to be with “easy to upgrade”?

Is this asking about the terminology, or asking how much effort we want to put into tools/docs to reach a point where we can say an upgrade is “easy” (whatever we decide that means)?

What does “full support” mean in the context of older majors? Do we need to clarify it more?

I’d prefer to communicate what people can expect during each period:

• Active development
• Bug and security fixes
• Security fixes only

Does this policy need to specify beta/alpha release period for new majors?
How do we support community module maintainers to migrate their module to the next major release? What are some of the risks if community modules can not be updated to the latest major promptly?

I’m answering these together because I think they’re linked. Clearly defined alpha/beta phases will give module authors a chance to plan ahead so that they can, if they choose, provide support for a major release on day 1. It should also aid early adoption and testing because if we have a clearly defined release schedule including alpha/beta phases then projects in development are more likely to take up those pre-release versions.

It’s hard to be precise with alpha/beta phases and how long they’ll take for obvious reasons, but I think it would be useful to define a pre-release period.

[rb1t]

I’d prefer to communicate what people can expect during each period:

Active development
Bug and security fixes
Security fixes only

👍

[chrispenny]

Firstly I just want to say how exciting this is! I'm really glad to see this change coming in, and I think it can (overall) only be positive for the future of Silverstripe.

More frequent smaller major releases at regular intervals will allow us to upgrade our dependencies more effectively.

Speaking for myself, the other benefit I see is that it's going to keep me more active on the modules that I support. If these PHP 8 upgrades have taught me anything, it's that I can quite easily go [years] without thinking about a module, and then when upgrade time rolls around, I'm way behind the ball as I haven't been proactive with them.

This will also benefit Silverstripe CMS project owners by enabling them to plan their upgrades with greater confidence.

100% this. Some of our enterprise clients are currently quite reluctant to pick up minor upgrades due to previous upgrades [blowing out]. At the moment it's reasonably common for us to skip 3 or even 4 minor versions.

If we can re-set expectations, and prove that minors are now [as easy as they advertise], then I think we'll have a much higher adoption rate of new releases.

When does a third party library become part of the CMS API?

IMO: As soon as a developer can interact with the CMS API in a way that would change due to a breaking dependency update.

I don't think that this needs to include the the possibility that a developer has completely overridden a method (say by extending the class and using Injector), but I think that it should include considerations around the fact that a developer could access (say) protected methods and properties through Injector.

How specific do we want to be with “easy to upgrade”?

Transparency is key. I'm not sure you need to promise that every upgrade will be "easy".

The issue is that there’s no overlap. If CMS4 is supported until December 31st 2024 and CMS6 is released “Q1 2026” then there’s a period of a couple of months (ish) where you’re running unsupported software without being able to upgrade yet.
...

I definitely mimic Lozzer's thoughts here. Some overlap would be incredibly beneficial.

EG: If we find ourselves in a position where we're having to tell someone that their version of Silverstripe is EOL in [x] months, then we really do need to be able to upgrade to the latest version. It won't go down well if we're having to say "but we can only upgrade to version [y] now, and then version [z] is out in 3 more month".

[jakxnz]

we really do need to be able to upgrade to the latest version.

I totally see the validity of bringing an upgrade all the way to latest.

Personally, I wouldn't anticipate leapfrogging an upgrade to be easier than stepping through sequentially. When a platform has clear upgrade pathways, the path of least resistance is to upgrade sequentially. For example, going from 1.x -> 1.99 -> 2.0 -> 2.99 -> 3.0. When the software provides upgrade pathways, stepping through versions encounters clear signposts.

Would providing overlap encourage people to shortcut progression, which increases their risks and also adversely reflects on the user experience?

Also, setting the climate to pursuade sequential upgrades makes automation more practical, because automation can "play through" a sequence of updates if the underlying design is predicated on that.

[mfendeksilverstripe]

I'm really happy to see this policy proposal as I think it covers a lot of the pain-points we experienced.

Do we want to extend the “limited support” of old major's so people can choose to skip Majors? E.g.: Upgrade from CMS4 to CMS6 bypassing CMS5?

My recommendation is to motivate people to upgrade gradually and avoid skipping upgrades. Skipping upgrades usually leads to a larger, more complex upgrade process which needs more effort compared to several smaller upgrades.

I also noticed that skipping upgrades leads to this strange loop:

• we don't do regular upgrades because upgrades are hard
• upgrades are hard because we don't do them regularly

Is there a preferred major release cadence? What would be the rationale for your suggestion? Do we want to reduce the support period for old Majors to 1 year?

Two year cadence is my preference as it represents a reasonable tradeoff between supporting old versions and avoiding too many upgrades needed to keep up.

How do we decide which dependencies are “fixed dependencies”? Do we need an objective criteria or can we do it just by fiat?

I'm not sure if there is a general rule to follow here. Probably needs a case-by-case approach.

When does a third party library become part of the CMS API? When we subclass their class

Yes, I think that's reasonable.

How specific do we want to be with “easy to upgrade”?

I think every major version should highlight areas that were changed. The ease of upgrade usually depends on amount of customisation of different areas. Some project may find it to upgrade easily but others may struggle. It's probably impossible to measure the ease of upgrade in general.

Does this policy need to specify beta/alpha release period for new majors?

I think betas are useful as projects can use it to estimate the upgrade effort. I suggest to specify the beta related information as a part of this policy.

[ChloeSartorelli]

If we find ourselves in a position where we're having to tell someone that their version of Silverstripe is EOL in [x] months, then we really do need to be able to upgrade to the latest version

In theory having this policy should make that situation a lot harder to get into - you'll know two years ahead of time when each major will be EOL.

But in reality I know it won't always work out that way - you might for example inherit a project from some other vendor who had neglected upgrading to the latest major, which would force you into this position. So from that standpoint I can definitely see how having some overlap could be a good thing.

In that case it's less about "I have chosen to skip a major version" and more "Someone else has chosen to avoid maintaining this site and now I need to clean up their mess - ideally by upgrading directly to the newest major instead of being forced to choose between having an EOL project for a few months or upgrading major versions once now and again in a few months"

[ChloeSartorelli]

When does a third party library become part of the CMS API?

• When we subclass their class (e.g.: SapphireTest)?
• When we expect a parameter of a specific type?
• When we return an instance of a class?

Honestly I think all of these count, assuming the methods expecting those parameters or returning those values are accessible to project code. As soon as a project can access the third party classes through Silverstripe classes they become part of the Silverstripe API.

[michalkleiner]

Is my understanding correct on this?

Currently, we are holding off on major changes and doing workarounds since we don't have the next major in sight and we don't want to break semver.
With the new policy adopted, we will have a new major in sight in say 1 or 2 years. It's an improvement, but for some changes that might still realistically equal to never/too far out.

So reinstating major releases and having them planned helps a bit, but is there an alternative without an actual fixed release cycle where we would remove all the weight from the major versions and iterate even faster, e.g. one a year or 'as needed' sort of thing?

Probably not feasible, but when I was rambling about not having new major releases in past I also didn't imagine keeping it as strict and as planned as proposed, but it might be the best way to go for a reliable/mature software Silverstripe CMS is aiming to be.

[MichAlkhouri]

This is brilliant. Having a policy provides visibility across board and in turn will help manage the client and project expectation. It will also standardise our processes, reduce dependancies and risks associated with lack of visibility. This is a step in the right direction. A review of this doc next year and the year after will give an indication if the policy needs any tweaking. I would recommend a wider conversation at Silverstripe on the implementation, from an operation perspective, of this policy and it’s indicative timeline. From testing perspective this going to make my life easier as I can have a clear discussion with the client and the project on what to expect therefor I can plan what to test. Thank you