Yes. It's about compatibility.
With a fixed-supply token, the deployer gets the supply initially and then can send an allowance to a crowdsale contract which will then sell them from inventory.
With a minted token, the sale contract calls the tokens mint()
function with each sale to create the needed tokens on-the-fly.
If you mix up incompatible types, you could have a mintable crowdsale calling a non-existent mint
function in the token contract. This strikes me as the obvious reason to have two variants - either you do or you don't want that step.
If I'm not mistaken, you can use a mintable token with an allowance-style sale. In that case, the minter
would occasionally mint more tokens and send them to the crowdsale.
In any case, test your implementation thoroughly. It's a best practice to publish a code audit publicly so your buyers have some assurance that there is no oversight in the finished product.
Hope it helps.